On Friday 17 July 2009 01:36:37 Carmelo AMOROSO wrote:
> I've recently added for testing hidden_proto in {m,re,c}alloc functions to
> ensure that from within the libc we always called the hidden __GI_xxx
> symbols.
>
> Using this uClibc with firefox and bash I found a problem.
> Both bash and firefox provide a their own implementation of memory
> allocation functions (bash internally, firefox by libejmalloc.so).
>
> Because the dynamic linker will search undefined symbols firstly in the
> application, any reference to malloc/free functions will be resolved by the
> application's symbols.
>
> If we use the hidden_protos, calls to malloc/free from libc are resolved
> inside libc itslef at it is expected.
>
> Now we have getcwd and strdup that use malloc for allocate memory and
> return the pointer to the caller. This memory is after freed by the
> application, calling free(), that is not the libc one implementation,
> leading to error, sigbus and so on.
>
> Do you think it is wrong to use the hidden_protos for this class of
> functions, or we should think better at how internal symbols are actually
> used by uClibc ?
i didnt quite understand this e-mail originally. i thought you were saying
you added tests only, not that you also added the hidden aliases to the
allocation functions. if you want to make a new config option ("Allow malloc
to be overridden dynamically"), that's fine. but the default should be what
we have today -- the malloc symbols can be resolved dynamically at runtime.
this is how many debugging libraries work in the first place -- they provide
the malloc() and related symbols.
i dont know what you mean by "think better" as the current stuff should be
correct already. the number of relocs in the C library is very small for
functions which is the point of these hidden aliases. looking at latest git i
see one or two missing, but those should be easy to fix.
-mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
