This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: [PATCH] Move DONT_USE_BOOTSTRAP_MAP defininition to dl-machine.h


> Note that i386-linux glibc build segfaults in ld.so ATM too (while
> i686-linux works), both using gcc 3.2. In that case it seems like
> %ebx was not set up as early as needed before _dl_start first references it.

I cannot reproduce this with my gcc (3.2-0.2 maybe?) using -O1 -march=i386
but did with -O3 -march=i386.  I think it is just happenstance that this
did not bite before (if it did not) and is not related to the
DONT_USE_BOOTSTRAP_MAP changes per se.  I think it bites i386 because
HP_TIMING_AVAIL is not defined and so the `start_time' reference in the
beginning of _dl_start never happens.  Without that reference, the compiler
doesn't think it needs to have set up the GOT register by the time the
elf_machine_load_address code presumes it's there.  I added a hack to the
asm in elf_machine_load_address to fool the compiler into thinking there is
a global variable reference, and that fixed it so it doesn't crash any more.

However, I am concerned that the presumptions about %ebx in dl-machine.h
(elf_machine_load_address and elf_machine_dynamic) may bite us again at
some point.  If _dl_start makes no calls through the PLT, the compiler no
longer necessarily uses %ebx for the GOT register.  If we added more
attribute_hidden or hidden_proto decls for _dl_* as we probably should,
there would in fact be no PLT calls.  

I have been experimenting a little just now and I think we can arrange for
the compiler to emit this code for us and avoid the register assumption.
For elf_machine_dynamic I think a plain reference to _DYNAMIC should be
fine, right?  _DYNAMIC@GOT just produces 0.  For elf_machine_load_address,
I have gotten the compiler to reproduce the same pair of instructions
(actually, when scheduling for i686 it decides that three are better than
two) by using a pair of decls:

extern char foobar __attribute__ ((visibility ("hidden")));
extern char foobar_x asm ("foobar");

int foo (void) { return &foobar - &foobar_x; }


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