I am pulling my hair out on ducking low level stuff. This is why people (more importantly me!) should have the chance to learn, rather than assume how things work.

Has anyone of you detailed resources on how linking objects into shared libraries really works ? Especially Name Resolution. All those ducking tutorials and bloody blog post just have simple examples and explain shit not in detail!

Even ducking man pages on gcc/ld don’t help me out! Maybe I’m too dumb to type the right words into me search engine. I’d even love to read a bloody paper book.

  • 3
    @dder If you have a demo project and a way of communicating, yes.

    I could explain a lot.
  • 4

    LLD has a lot of internal documentation.

    It should be a good starting point
  • 2
    What specifically is confusing you? Name resolution is simple unless youre working with C++ in which case it's compiler specific.
  • 1
    I’m trying to replace a c implemented function in a huge library by an assembly one, cause I think I can do better then the compiler. Then I want to build that lib with either function, load both at runtime and run their wrapper function which eventually calls my replaced function. I’m doing that to measure how many less cycles my implementation uses.

    So I removed the definition of that function in the lib, leaving only the declaration, then compile the lib to objects, assemble my function to an object and link all together to a shared object.

    However, linking that lib with my object, sorta works (as in my code is in the lib, verified w objdump) but that particular symbol is not used. Instead, that C-declared symbol in part of the lib, and whenever it’s being called from that wrapper it searches for that Symbol dynamically and does not call my own one but find some other.
  • 0
    *I don’t want that do be SO, I’m just using you guys as my rubber duck I suppose*

    The strange thing is, I can link everything together into a shared object without my function object and the linker is not complaining. I don’t understand why (I suppose not all symbols need to be resolved in a shared obj, cause that MAY be linked in a later stage).
    Thing is, I want the linker to link that symbol, that one that I just declared in C, to my own bloody object!
  • 0
    @IntrusionCM I’ll give the llvm linker a go, thanks!
    Maybe I’ll even put an MWE on SO waiting to get roasted or ignored there! Is there a compiler sub-stackexchange for that ? I mean it’s not really programming šŸ˜•
  • 0
    @dder I think I have a tiny idea what you're trying to do.

    Read it multiple times, but not entirely sure.

    Read the following please:


    If the symbol of assembler and c function is same, it should work.
  • 0
    @IntrusionCM I've been at that LD_PRELOAD trick already. But that's not the problem. Using that, I can not use two different external symbols. E.G. in my_prog.c i call foo(), which shall be defined in a.so and in b.so. Using `LD_PRELOAD=a.so:b.so ./a.out` then does not allow me to switch between a's foo and b's boo (afaik, RTLD_NEXT is not "traversing" through all definitions, its just giving 'the other then the one locally' symbol. And since foo() is not in my_prog.c, I'll always get a's foo symbol.

    That being said, I use h_a = dlmopen(-1, `a.so`) to load a.so; then get wrapper symbol from h_a, which should then call foo() inside of a.so. same for b.so. However, since I am unable to link foo() 'statically' into b.so, when I then call h_b.foo() it searches foo, and finds something else (cause it ain't crashing), but I don't know which one. (may be /usr/lib/SYSTEM_LIB.so, which is not linked to b.so (according to `ldd b.so` or `ldd a.out`))

    HENCE, I want to understand how linkin werks
  • 0
    @IntrusionCM symbols are the same name, but in a.so, foo is a local symbol for a function (objdump -t a.so `l F`) and in b.so my linked symbol is just a normal global `g .text` (which is the one that I want(yey!) but is removed, if i strip unused symbols from it -Wl,--gc-symbols) or just a normal symbol ` *UND*` with size 0 (I assume that's from my C-declaration).

    So how the bloody fuck do I get my symbol locally into that shared object, replacing that *UND* symbol.
  • 1
    @dder I'll write a short demo tomorrow I think.

    LD preload should be the right thing for that - and you should only load - one - library with preload, as my-prog should be linked with the other.

    Brain is to tired to wade through the wall of text, but I think you should either generate a small demo project yourself and upload it eg to a GIST / github or wait till tomorrow...

    Whole your descriptions are not bad per SE, it's extremely hard to follow.

    A makefile, a bash script or anything that has the concrete commands you do would be far better than that mass of text. :/
  • 0
    fuck, in my mwe it works.


    @IntruisionCM no need to do an example as of now. Ill ping here, if I manage to break it.

  • 0
    If you're writing a C function export in assembly, prefix it with an underscore.

    void my_function() {}


    sub _my_function:

    Or however your flavor of asm defines subroutines. Make sure to export it (there's usually a directive for it). Also when in doubt, call it something unique (like my_totally_unique_function) and then grep the output of nm to see its linkage. You want T (capital) if memory serves.
  • 0
    @junon im using nasm and intel syntax, and that works, as shown in me github. I dont think there is any name mangling going on, I can see the symbols as I expect in objdump...

    Its a different problem, which has to do with the greater projects, which I am not thinking about right now...
    I am assuming the wrong things somewhere...

    Ill give it a rest, some beers, and try Monday
    But thanks for suggesting! Appreciate!
  • 0
    @dder Good luck, would love to hear what the problem was if you figured it out :)
  • 1
    @junon well, less exiting, I was missing a define so some functions never were in the compile context at all. So I was looking at the wrong place. Thanks anyway for your support :)
  • 0
    @dder No problem, glad you got it figured out :) Thanks for the update!
Add Comment