lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] OFFSET globals
Date Tue, 24 Apr 2012 03:38:46 GMT
On Mon, Apr 23, 2012 at 12:49 PM, Nathan Kurz <nate@verse.com> wrote:
> On Mon, Apr 23, 2012 at 7:55 AM, Marvin Humphrey <marvin@rectangular.com> wrote:
>> My understanding is that in the event that two ELF DSOs export the same
>> symbol, the general rule is that the last library loaded wins[1]:
>
> I'm pretty sure that at runtime it's the first definition found that
> wins, which is why LD_PRELOAD can be used to override functions like
> malloc().
>
>>    http://www.akkadia.org/drepper/dsohowto.pdf
>
> "Note that there is no problem if the scope contains more than one
> definition of the same symbol. The symbol lookup algorithm simply
> picks up the first definition it finds." p.6, 1.5.2

Ah, that's a better quote than the one I found.  Thanks!

This page has more on symbol resolution, and it's a little more approachable
than the Drepper:

    http://www.bottomupcs.com/libraries_and_the_linker.html

    It is often very useful for a programmer to be able to override a symbol
    in a library; that is to subvert the normal symbol with a different
    definition.

    We mentioned that the order that libraries is searched is given by the
    order of the DT_NEEDED fields within the library. However, it is possible
    to insert libraries as the last libraries to be searched; this means that
    any symbols within them will be found as the final reference.

    This is done via an environment variable called LD_PRELOAD which specifies
    libraries that the linker should load last.

    ...

    We have seen how we can override a function in another library by
    preloading another shared library with the same symbol defined. The symbol
    that gets resolved as the final one is the last one in the order that the
    dynamic loader loads the libraries.

    Libraries are loaded in the order they are specified in the DT_NEEDED flag
    of the binary. This in turn is decided from the order that libraries are
    passed in on the command line when the object is built. When symbols are
    to be located, the dynamic linker starts at the last loaded library and
    works backwards until the symbol is found.

> I've been planning to chime in on this, but haven't had time to do it
> justice.  My quick thoughts are that:
>
> 1) This can and should be solved through DSO symbol versioning.

Hmm, I'm not sure that the problem we're working on can actually be solved
this way.  What we're tying to protect against is the possible *removal* of a
symbol.  I don't see how you guard against that using DSO symbol versioning.

> 2) It's great to get things right so as to have a solid foundation, but
> 3) We got along just fine for years without actually implementing this, thus
> 4) We don't need to solve this right now, just future-proof ourselves.

Well, the reason we're working on this now is that Nick wants to write
compiled extensions, and we want to be able to update Lucy without breaking
his compiled extensions.  We haven't needed this until now because we haven't
supported compiled extensions, but that's changing!

> I'm rusty and busy, though, and might not be of immediate help.  In
> addition to Ulrich's paper, Ian's series here might be a good
> refresher: http://www.airs.com/blog/page/4?s=%22linkers+part%22
>
> I haven't found a good overview of the links, but versioning is covered in
> Part 9: Symbol Versions http://www.airs.com/blog/archives/46
> Part 13: Symbol Versions Redux http://www.airs.com/blog/archives/50

Thanks for these links (and for being the first to introduce Drepper's paper
to me a while back).  I've been wondering if DSO symbol versioning could help
us.  After reading these materials, I'm reasonably sure it cannot --
though if I'm
wrong, I would be excited to learn why!

Marvin Humphrey

Mime
View raw message