[PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
Carmelo AMOROSO
carmelo.amoroso at st.com
Thu Sep 4 08:33:05 UTC 2008
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, at -r15
> mov.l r14, at -r15
> sts.l pr, at -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, at -r15
> sts.l pr, at -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"
>
More information about the uClibc
mailing list