[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