__uc_malloc hooks

Denys Vlasenko vda.linux at googlemail.com
Sat Sep 15 18:09:20 UTC 2007


On Saturday 15 September 2007 09:19, Mike Frysinger wrote:
> On Monday 30 July 2007, Denis Vlasenko wrote:
> > I don't quite understand how to do hiding of __uc_malloc and
> > __uc_malloc_failed. I see several different usage patterns for
> > XXX_hidden_XXX macros,
> > and also see open-coded attribute defs.
> 
> the hidden stuff is all documented in include/libc-symbols.h ... if, after 
> reading that, there's something missing, just lemme know and i'll do a 
> human-readable brain dump on the topic ... at first (and second and 
> third ...) go, they can be hard to digest

Reading.

>/* The following macros are used for PLT bypassing within libc.so
>   (and if needed other libraries similarly).
>   First of all, you need to have the function prototyped somewhere,
>   say in foo/foo.h:
>
>   int foo (int __bar);
>
>   If calls to foo within libc.so should always go to foo defined in libc.so,
>   then in include/foo.h you add:
>
>   libc_hidden_proto (foo)
>
>   line and after the foo function definition:
>
>   int foo (int __bar)
>   {
>     return __bar;
>   }
>   libc_hidden_def (foo)
>
>   or
>
>   int foo (int __bar)
>   {
>     return __bar;
>   }
>   libc_hidden_weak (foo)

I have several questions. first one:

libc_hidden_def (foo) /* whan to use this?... */
libc_hidden_weak (foo) /* ...and when this? */

Next. In actual uclibc code, usage is different. For example, libc_hidden_proto(mmap)
and libc_hidden_def(mmap) are scattered in 16 files. 15 of them .c files and
remaining one is malloc.h. Why?

Next. The names of thse macros are not decriptive. "libc_hidden_def(foo)". Hmmm.
It must be a "hidden definition of foo"? 

# define libc_hidden_def(name) hidden_def (name)

oh..

# define hidden_def(name)              __hidden_ver1(__GI_##name, name, name);

omg..

#  define __hidden_ver1(local, internal, name) \
   extern __typeof (name) __EI_##name __asm__(__hidden_asmname (#internal)); \
   extern __typeof (name) __EI_##name __attribute__((alias (__hidden_asmname1 (,#local))))

shoot me someone

#  define __hidden_asmname(name) __hidden_asmname1 (__USER_LABEL_PREFIX__, name)
#  define __hidden_asmname1(prefix, name) __hidden_asmname2(prefix, name)
#  define __hidden_asmname2(prefix, name) #prefix name

I put my propeller hat on.

What is __USER_LABEL_PREFIX__? It is never defined.

So it is converted into

extern __typeof (foo) __EI_foo __asm__(__USER_LABEL_PREFIX__"foo");
extern __typeof (foo) __EI_foo __attribute__((alias ("__GI_foo")));

Hrm, so __USER_LABEL_PREFIX__ will vanish? Why? Oh well...

Ok, googling...
So "__EI_foo" in C will be equivalent to "foo" in asm. Why is this needed?

Anyway I have a feeling that I am lost in the #define maze
and the only thing which I understand is that

libc_hidden_def(foo)

is not a "hidden definition of foo", it's a "definition of hidden symbol
_MAGIC_JUNK_foo which is aliased to foo", and

libc_hidden_proto(foo)

is not a "hidden prototype of foo" but rather "please make all references
to foo in this .c file refer to _MAGIC_JUNK_foo".

Which is utterly confusing.

Can I have macro names which do not lie to me?

libc_define_internal_alias(foo)
  [or libc_define_internal_name(foo) or libc_define_internal(foo) or...]
and
libc_use_internal_alias(foo)

> more to the point ... how exactly would __uc_malloc be useful ?  i dont think 
> ive ever seen malloc() return NULL as the kernel is the first to find out 
> about the OOM situation and properly nukes any userspace app before it ever 
> sees the relevant NULL ...

malloc may fail because this particular process has memory limits set:

softlimit -m 300000 passwd

(softlimit is a busybox applet)
--
vda



More information about the uClibc mailing list