[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