Re: Resolved: Re: An assignment isn't being executed.

Discussion in 'C Programming' started by Fred, Oct 5, 2011.

  1. Fred

    Fred Guest

    On Oct 5, 4:12 am, China Blue Corn Chips <> wrote:
    > In article <-september.org>,
    >  China Blue Corn Chips <> wrote:
    >
    > > I have an assignment which should be

    >
    > It seems position independent code is broken. Suppressing that and using static
    > libraries fixes the problem.
    >


    It appears the "offending" statement is:

    (((GC_arrays._top_index [(word)(h) >> (10 +
    ((size_t)12))]))->index[((word)(h) >> ((size_t)12)) & ((1 << 10) -
    1)]) = (result);

    I would probably get fired if I wrote code like that.

    Break that into several statements so you can check what is
    really happening in both scenarios (with/without PIC):

    shiftA = ((1 << 10) - 1);
    shiftB = (word)h >> ((size_t)12));
    idx1 = shiftB & shiftA;
    shiftC = (10 + ((size_t)12));
    idx2 = (word)(h) >> shiftC;
    structA =((GC_arrays._top_index [idx2]));
    structA->index[idx1] = result;

    -- Fred K
     
    Fred, Oct 5, 2011
    #1
    1. Advertising

  2. Fred

    Fred Guest

    On Oct 5, 11:12 am, China Blue Corn Chips <>
    wrote:
    > In article <..com>,
    >
    >
    >
    >
    >
    >  Fred <> wrote:
    > > On Oct 5, 4:12 am, China Blue Corn Chips <> wrote:
    > > > In article <-september.org>,
    > > >  China Blue Corn Chips <> wrote:

    >
    > > > > I have an assignment which should be

    >
    > > > It seems position independent code is broken. Suppressing that and using
    > > > static
    > > > libraries fixes the problem.

    >
    > > It appears the "offending" statement is:

    >
    > >     (((GC_arrays._top_index [(word)(h) >> (10 +
    > > ((size_t)12))]))->index[((word)(h) >> ((size_t)12)) & ((1 << 10) -
    > > 1)]) = (result);

    >
    > > I would probably get fired if I wrote code like that.

    >
    > It's free software that works (usually).
    >
    > > Break that into several statements so you can check what is
    > > really happening in both scenarios (with/without PIC):

    >
    > Recompiling everything with -fno-pic solved the problem, so it's some kind issue
    > with I386 PIC. I can work with this restriction, so I'm not going to go further
    > with this. I'm now back to debugging my own code which is where I want tobe.
    >


    I would be very suspicious of any free software that used such
    outrageous coding:
    (10 + ((size_t)12)) instead of just 22 ?

    It would be much better to determine what it is trying top do, and re-
    write it correctly.
    --
    Fred K
     
    Fred, Oct 5, 2011
    #2
    1. Advertising

  3. Fred

    jacob navia Guest

    Le 05/10/11 23:01, Fred a écrit :
    >
    > I would be very suspicious of any free software that used such
    > outrageous coding:
    > (10 + ((size_t)12)) instead of just 22 ?
    >
    > It would be much better to determine what it is trying top do, and re-
    > write it correctly.
    > --
    > Fred K


    You are seeing the output of the preprocessor Fred. The software is
    Boehm's GC software and the original code looks like this
    (in src/boehm_gc/headers.c):

    1 /* Install a header for block h. */
    2 /* The header is uninitialized. */
    3 /* Returns the header or 0 on failure. */
    4 struct hblkhdr * GC_install_header(struct hblk *h)
    5 {
    6 hdr * result;
    7
    8 if (!get_index((word) h)) return(0);
    9 result = alloc_hdr();
    10 SET_HDR(h, result);
    11 # ifdef USE_MUNMAP
    12 result -> hb_last_reclaimed = (unsigned short)GC_gc_no;
    13 # endif
    14 return(result);
    15 }

    You are seeing the preprocessor output for line 10, the SET_HDR macro.

    THAT IS WHY it looks so "horrible".

    The problem is that China Blue Corn Chips did not recompile all objects
    and the pointer loaded for the GC_arrays._top_index was wrong. When he
    recompiled everything the bug disappeared because he recompiled
    everything NOT because he changed to -fno_pic

    Now, since he is happy now it is not worth the effort to go on
    debugging his problem...

    If the compiler would not emit correctly assignments with -fpic
    that would be surely known :)

    I verified the assembly code and the emitted code is OK:

    (((GC_arrays._top_index [(word)(h) >> (10 +
    ((size_t)12))]))->index[((word)(h) >> ((size_t)12)) & ((1 << 10) - 1)])
    = (result);


    movl 8(%ebp), %eax // fetch argument "h"
    movl %eax, %edx
    shrl $22, %edx // h >> 22
    // Here in the line below is the wrong pointer
    leal L_GC_arrays$non_lazy_ptr-"L00000000008$pb"(%ebx), %eax
    // dereference it
    movl (%eax), %eax
    // fetch index
    movl 123500(%eax,%edx,4), %ecx
    // fetch h
    movl 8(%ebp), %eax
    // shift 12
    shrl $12, %eax
    movl %eax, %edx
    // ((1 << 10) - 1) --> 1023
    andl $1023, %edx
    // fetch "result"
    movl -12(%ebp), %eax
    // store it
    movl %eax, (%ecx,%edx,4)

    The only suspect line is

    leal L_GC_arrays$non_lazy_ptr-"L00000000008$pb"(%ebx), %eax

    That offset could have changed because of some header file changing
    or a incoherence introduced by some modification in the object
    files...
     
    jacob navia, Oct 5, 2011
    #3
  4. Fred <> writes:

    > On Oct 5, 11:12 am, China Blue Corn Chips <>
    > wrote:
    >> In article <>,
    >>
    >>  Fred <> wrote:
    >> > On Oct 5, 4:12 am, China Blue Corn Chips <> wrote:
    >> > > In article <-september.org>,
    >> > >  China Blue Corn Chips <> wrote:

    >>
    >> > > > I have an assignment which should be

    >>
    >> > > It seems position independent code is broken. Suppressing that and using
    >> > > static
    >> > > libraries fixes the problem.

    >>
    >> > It appears the "offending" statement is:

    >>
    >> >     (((GC_arrays._top_index [(word)(h) >> (10 +
    >> > ((size_t)12))]))->index[((word)(h) >> ((size_t)12)) & ((1 << 10) -
    >> > 1)]) = (result);

    >>
    >> > I would probably get fired if I wrote code like that.

    >>
    >> It's free software that works (usually).
    >>
    >> > Break that into several statements so you can check what is
    >> > really happening in both scenarios (with/without PIC):

    >>
    >> Recompiling everything with -fno-pic solved the problem, so it's some kind issue
    >> with I386 PIC. I can work with this restriction, so I'm not going to go further
    >> with this. I'm now back to debugging my own code which is where I want to be.
    >>

    >
    > I would be very suspicious of any free software that used such
    > outrageous coding:
    > (10 + ((size_t)12)) instead of just 22 ?


    The expression comes from the expansion of a macro. The macro may be
    suspect (I don't know) but calculating sizes from other constants is a
    common thing to do in portable macros.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Oct 5, 2011
    #4
  5. Ben Bacarisse wrote:
    > Fred <> writes:
    >
    >> On Oct 5, 11:12 am, China Blue Corn Chips <>
    >> wrote:
    >>> In article <>,
    >>>
    >>> Fred <> wrote:
    >>>> On Oct 5, 4:12 am, China Blue Corn Chips <> wrote:
    >>>>> In article <-september.org>,
    >>>>> China Blue Corn Chips <> wrote:
    >>>>>> I have an assignment which should be
    >>>>> It seems position independent code is broken. Suppressing that and using
    >>>>> static
    >>>>> libraries fixes the problem.
    >>>> It appears the "offending" statement is:
    >>>> (((GC_arrays._top_index [(word)(h) >> (10 +
    >>>> ((size_t)12))]))->index[((word)(h) >> ((size_t)12)) & ((1 << 10) -
    >>>> 1)]) = (result);
    >>>> I would probably get fired if I wrote code like that.
    >>> It's free software that works (usually).
    >>>
    >>>> Break that into several statements so you can check what is
    >>>> really happening in both scenarios (with/without PIC):
    >>> Recompiling everything with -fno-pic solved the problem, so it's some kind issue
    >>> with I386 PIC. I can work with this restriction, so I'm not going to go further
    >>> with this. I'm now back to debugging my own code which is where I want to be.
    >>>

    >> I would be very suspicious of any free software that used such
    >> outrageous coding:
    >> (10 + ((size_t)12)) instead of just 22 ?

    >
    > The expression comes from the expansion of a macro. The macro may be
    > suspect (I don't know) but calculating sizes from other constants is a
    > common thing to do in portable macros.


    .... and in self-documenting (or at least hinting) code.

    > <snip>
     
    J. J. Farrell, Oct 6, 2011
    #5
  6. Fred

    Eric Sosman Guest

    On 10/5/2011 5:01 PM, Fred wrote:
    >[...]
    > I would be very suspicious of any free software that used such
    > outrageous coding:
    > (10 + ((size_t)12)) instead of just 22 ?


    It's obviously a macro expansion. Remember macros?

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 6, 2011
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bid
    Replies:
    1
    Views:
    416
    Srinivasa Reddy K Ganji
    Jul 21, 2003
  2. crjunk
    Replies:
    2
    Views:
    16,841
    crjunk
    Aug 8, 2003
  3. PERCIVAL BRAGG
    Replies:
    0
    Views:
    551
    PERCIVAL BRAGG
    Oct 15, 2003
  4. Pieter Claassen

    hash table problems being resolved

    Pieter Claassen, Aug 16, 2004, in forum: C Programming
    Replies:
    2
    Views:
    295
    Pieter Claassen
    Aug 16, 2004
  5. Peter Morris

    Application_Start isn't executed

    Peter Morris, Jan 5, 2009, in forum: ASP .Net
    Replies:
    2
    Views:
    743
    Peter Morris
    Jan 6, 2009
Loading...

Share This Page