This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Compiler bug in gcc?


Hello all,

I'm currently building a Newlib-based linux-x-freebsd cross-compiler and am
having a wee bit of trouble with what I think might be a compiler/optimiser
bug in gcc.

The function __do_global_ctors_aux gets called from the .init section, from 
a _init function from _start, which I wrote. (On i386-unknown-freebsd4.7 the
.init section contents apparently doesn't get run automatically, but needs to
be called from _start, so I wrapped a function definition around it and call
it from _start.

The code in gcc of the body of this function is in a macro called 
DO_GLOBAL_CTORS_BODY, which looks like this:
do {                                                                    \
  unsigned long nptrs = (unsigned long) __CTOR_LIST__[0];               \
  unsigned i;                                                           \
  if (nptrs == (unsigned long)-1)                                       \
    for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++);            \
  for (i = nptrs; i >= 1; i--)                                          \
    __CTOR_LIST__[i] ();                                                \
} while (0)

gcc, configured with 
$ ../src/configure --prefix=$PREFIX --target=$TARGET --with-newlib \
  --with-gnu-as --with-gnu-ld --disable-shared --disable-threads \
  --enable-languages=c,c++

produces this: (disassembled by gdb)

Dump of assembler code for function __do_global_ctors_aux:
0x8054b98 <__do_global_ctors_aux>:      push   %ebp
0x8054b99 <__do_global_ctors_aux+1>:    mov    %esp,%ebp
0x8054b9b <__do_global_ctors_aux+3>:    push   %ebx
0x8054b9c <__do_global_ctors_aux+4>:    push   %edx
0x8054b9d <__do_global_ctors_aux+5>:    mov    0x8057194,%eax
0x8054ba2 <__do_global_ctors_aux+10>:   cmp    $0xffffffff,%eax
0x8054ba5 <__do_global_ctors_aux+13>:   mov    $0x8057194,%ebx
0x8054baa <__do_global_ctors_aux+18>:   je     0x8054bb8 <__do_global_ctors_aux+32>
0x8054bac <__do_global_ctors_aux+20>:   sub    $0x4,%ebx
0x8054baf <__do_global_ctors_aux+23>:   call   *%eax
0x8054bb1 <__do_global_ctors_aux+25>:   mov    (%ebx),%eax
0x8054bb3 <__do_global_ctors_aux+27>:   cmp    $0xffffffff,%eax
0x8054bb6 <__do_global_ctors_aux+30>:   jne    0x8054bac <__do_global_ctors_aux+20>
0x8054bb8 <__do_global_ctors_aux+32>:   pop    %eax
0x8054bb9 <__do_global_ctors_aux+33>:   pop    %ebx
0x8054bba <__do_global_ctors_aux+34>:   leave
0x8054bbb <__do_global_ctors_aux+35>:   ret
End of assembler dump.

The error is that %ebx is not saved before thet call to *%eax, and is 
not guaranteed to be preserved which, in fact, it is not.

I have attached the transcript of a gdb session on a simple test case, and 
the simple test case itself, to this E-mail. My questions are obviously:
* am I right in presuming this is a bug?
* if so, should I add it to the bugzilla?
* is there any known work-around for this?

Any pointers, comments, etc. will be very welcome.

rlc

-- 
There's an old proverb that says just about whatever you want it to.

Attachment: gdb-session
Description: Text document

Attachment: main.cpp
Description: Text document

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]