[PATCH] doubt in _dl_exit

Bernhard Fischer rep.dot.nop at gmail.com
Tue Jun 3 13:23:09 UTC 2008


On Tue, Jun 03, 2008 at 02:27:08PM +0200, Carmelo AMOROSO wrote:
> Bernhard Fischer wrote:
>> On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote:
>>   
>>> Bernhard Fischer wrote:
>>>     
>>>> Could somebody who uses ldso please have a look if this breaks his
>>>> setup?
>>>>
>>>> $ size ldso/ldso/ldso.oS*
>>>>    text	   data	    bss	    dec	    hex	filename
>>>>   12424	     12	     72	  12508	   30dc	ldso/ldso/ldso.oS.old
>>>>   12290	     12	     72	  12374	   3056	ldso/ldso/ldso.oS
>>>>
>>>> @@ -59,7 +59,11 @@
>>>>     dynamic linking at all, so we cannot return any error codes.
>>>>     We just punt if there is an error. */
>>>>  #define __NR__dl_exit __NR_exit
>>>> -static __always_inline _syscall1(void, _dl_exit, int, status);
>>>> +static __always_inline attribute_noreturn void _dl_exit(int status)
>>>> +{
>>>> +	while (1)
>>>> +		INLINE_SYSCALL(exit, 1, status);
>>>> +}
>>>>          
>>> Hi Bernd,
>>> I've just now the chance to update my repo and figured out that this
>>> brakes sh4 build.
>>> My you explain the rationale for this change ?
>>>     
>>
>> http://busybox.net/lists/uclibc/2008-May/019394.html
>>
>> I'm not opposed to reverting that hunk but that explicit variant was
>> better, imho.
>>
>>   
> Hi,
> the problem is that it needs to update sh4/bits/syscall.h because it  
> doesn't define INLINE_SYSCALL macro.
> I'll see to update this... so let's keep this.

ah, i should have looked if the other arches also do it by
INLINE_SYSCALL and not assume they do. I don't want to touch the other
arches right now, so i'll revert this hunk in the evening (in a couple
of hours).

> At this point I support all other _syscall macro will be removed as well  
> to use the explicit variant ?

I didn't intend to look at ldso, no.
A janitorial thing somebody could do is make sure all arches are synced
so we can remove that errnoeous trailing ';' from
_syscall[[:digit:]][[:space:]]*(.*)



More information about the uClibc mailing list