internal_function problem

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Jun 24 06:43:57 PDT 2007


> -----Original Message-----
> From: Bernhard Fischer [mailto:rep.dot.nop at gmail.com] 
> Sent: den 24 juni 2007 11:56
> To: Joakim Tjernlund
> Cc: uclibc at uclibc.org
> Subject: Re: internal_function problem
> 
> On Sun, Jun 24, 2007 at 10:27:32AM +0200, Joakim Tjernlund wrote:
> >> -----Original Message-----
> >> From: Bernhard Fischer [mailto:rep.dot.nop at gmail.com] 
> >> Sent: den 23 juni 2007 22:07
> >> To: Joakim Tjernlund
> >> Cc: uclibc at uclibc.org
> >> Subject: Re: internal_function problem
> >> 
> >> On Sat, Jun 23, 2007 at 04:54:27PM +0200, Joakim Tjernlund wrote:
> >> 
> >> >It is internal to uClibc and should be empty outside libc
> >> 
> >> So i will commit the attached patch to trunk, ok?
> >> 
> >> - make sure to define _LIBC in libc-symbols.h before 
> >> including anything
> >>   else.
> >> - internal_function is only used inside libc, so do not 
> define it in
> >>   uClibc_arch_features.h on i386 if we are outside of libc.
> >> 
> >
> >Well, the idea makes sense but now internal_function
> >is undefined for non LIBC, isn't it?
> 
> No it isn't, see below.
> >I was thinking soemthing like this:
> >
> >#if defined _LIBC
> > #define internal_function __attribute__ ((regparm (3), stdcall))
> >#else
> > #define internal_function
> >#endif
> 
> in libc-symbols.h, around line 276, it is defined to empty already:
> /* On some platforms we can make internal function calls 
> (i.e., calls of
>    functions not exported) a bit faster by using a different calling
>    convention.  */
> #ifndef internal_function
> # define internal_function      /* empty */
> #endif
> 
> I think that it does not make sense to duplicate defining it 
> to empty in
> the arch specific internal helpers when this is already done 
> in an arch
> agnostic place.

Ah, I see.

> 
> Ok to apply as is?

I think so, give it a go :)

> >
> >Even better is to sanitize the headers so that
> >this stuff aren't visible outside uClibc at all, but that's
> >a different story :)
> 
> IIRC psm did this already after he gave up on applying stuff 
> to the repo :(
> 
> 



More information about the uClibc mailing list