__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