Paul Mundt wrote: > On Wed, Sep 03, 2008 at 05:47:56PM +0200, Carmelo AMOROSO wrote: >> Paul Mundt wrote: >>> On Tue, Sep 02, 2008 at 02:09:20PM +0200, Carmelo AMOROSO wrote: >>>> I did not success to create a test that could fail. >>>> application ctor/dtor defined by gcc attribute ((__contructor__)) on >>>> ((__destructor__)) are correctly invoked. >>>> Indeed, if I put the ctor/dtor in a separate object file and I build it >>>> as a PIC object, then the compiler will create the proper >>>> _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and >>>> use r12. >>>> Yes, glibc _init function does it, but I'm thinking that it is useless. >>>> I cannot see a scenario in which this may fail. Are we sure we need this >>>> code at all? or we simply have taken the code as is from glibc in the >>>> past ? >>>> >>> I expect it is just something that was blindly copied from glibc. I >>> wasn't the one that copied it in to uclibc originally, but I would wager >>> it's a sanity measure to work around old compilers. >>> >> interesting ! >>> The GCC ident references 3.3.2, I don't have anything that old sitting >>> around any more, >> neither I have. >>> but it might be worth testing out with something before >>> that to see if the proper entry is generated without the init/fini help >>> before deciding whether to axe the code completely or not. >>> >> Yoshii, are you able to try with older gcc ? or was you able to produce >> a testcase ? >> > Well, Sugioka-san has 3.04 and 2.97 binaries, but nothing beyond that. > On the other hand, we're not even realistically able to build the kernel > with anything that old, so it's likely not even worth bothering with. > > Given that, and the fact we don't have a test case that manages to trip > up the logic, we may as well just kill it off. The logic has been > completely inverted from day one also, so it's unlikely anyone seriously > tested or depended on this in the first place. If there were compiler > issues earlier on, the inverted logic would obviously not have fixed this > either. So, how about this? > Absolutely agreed. That's what I was thinking. Please commit.
Carmelo > --- > > libc/sysdeps/linux/sh/crti.S | 23 ----------------------- > 1 file changed, 23 deletions(-) > > Index: libc/sysdeps/linux/sh/crti.S > =================================================================== > --- libc/sysdeps/linux/sh/crti.S (revision 23132) > +++ libc/sysdeps/linux/sh/crti.S (working copy) > @@ -1,5 +1,3 @@ > -#include <features.h> > - > .file "crti.S" > .text > > @@ -12,19 +10,10 @@ > mov.l r12,@-r15 > mov.l r14,@-r15 > sts.l pr,@-r15 > -#ifndef __HAVE_SHARED__ > - mova .L6,r0 > - mov.l .L6,r12 > - add r0,r12 > -#endif > mov r15,r14 > bra 1f > nop > .align 2 > -#ifndef __HAVE_SHARED__ > -.L6: > - .long _GLOBAL_OFFSET_TABLE_ > -#endif > 1: > > .section .fini > @@ -37,19 +26,7 @@ > mov.l r14,@-r15 > sts.l pr,@-r15 > mov r15,r14 > -#ifndef __HAVE_SHARED__ > - mov.l .L11,r12 > - mova .L11,r0 > - add r0,r12 > -#endif > - > bra 1f > nop > .align 2 > -#ifndef __HAVE_SHARED__ > -.L11: > - .long _GLOBAL_OFFSET_TABLE_ > -#endif > 1: > - > - .ident "GCC: (GNU) 3.3.2" > _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc