[lsb-discuss] Best-effort dynamic linking -- take 1
Alexey Khoroshilov
khoroshilov at ispras.ru
Tue Jul 22 13:45:54 PDT 2008
Jeff Licquia wrote:
> Alexey Khoroshilov wrote:
>> Yes, the thing that was not clear here is why we should exit (i.e.
>> proceed with the nativelinker) if the LSB linker is a symlink.
>
> Thinking about this, it occurs to me that we should not just verify
> that the LSB linker is a symlink, but that it points to the native
> linker. If we add that test, does it make more sense to you?
>
That is exactly what I meant. Actually there is such test among my fixes:
// If lsblinker is not available, proceed with the nativelinker.
if (stat(lsb_linker_path, &lsblinker) != 0)
return;
// If stat() for nativelinker fails, proceed with the nativelinker.
if (stat(native_linker_path, &nativelinker) != 0)
return;
// If lsblinker == nativelinker, proceed with the nativelinker.
if (lsblinker.st_ino == nativelinker.st_ino)
return;
// If lsblinker is not a link to nativelinker, re-exec with lsblinker.
// We only abort on some failure or other.
>> After reading the last argument "while (*pos && argc < 128)"
>> dereferences the pos element, which is the next after the last
>> written by read(). And it is zero only if cmdbuf was initialized by
>> zeros.
>
> I could have sworn that the page describing cmdline mentioned that the
> last argument was followed by a "double zero", which would have made
> this OK. But I can't find that write-up now, and the test program I
> whipped up just now showed conclusively that no "double-zero" is present.
>
>> As far as I know (not sure) the heap manager initialization code is
>> executed during // the first invocation of malloc-family functions.
>> At least, malloc can be called by any C++ constructor, which can be
>> executed at the similar stage.
>
> And with older gcc, the order of initializers couldn't be guaranteed.
> Maybe gcc played some special magic, but I doubt it. I'll test using
> malloc and see how well it works.
I have found a source [1] confirming that the heap manager
initialization code is executed during the first invocation of
malloc-family functions:
0.3.1 Heap initialization
Heap initialization occurs the first time a request to allocate
memory is called, the
interface to create heaps, first one or otherwise is not publicly
exported and thus
cannot be explicitly accomplished, but rather implicitly by
attempting to
allocate memory. This step is almost always realized prior to the
developers first
call to malloc() or realloc() due to process/application
initialization done by the
step (by the time you call one of the allocation functions its
already been called
several times by libc code run during your process’ creation).
My experiments confirm this as well.
[1]
https://www.blackhat.com/presentations/bh-usa-07/Ferguson/Whitepaper/bh-usa-07-ferguson-WP.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080723/18f29d8f/attachment.htm
More information about the lsb-discuss
mailing list