CODEWITHSUNDEEP
cgcclinkershared-libraries
igk
igk

Reputation: 41

Why do ld, nm, objdump report 'no symbols' in this shared object, when symbols appear to exist?

I have an undocumented shared object, libXSAL.so, which I would like to link against.

I have written a partial header file containing the functions I need, with signatures inferred from reverse engineering with Ghidra.

gcc fails at link time: undefined reference to 'function_name' for each of the functions I use.

nm -D libXSAL.so

nm: libXSAL.so: No symbols

objdump -t libXSAL.so

libXSAL.so:     file format elf32-little

SYMBOL TABLE:
no symbols

However, Ghidra spots the names of the functions as given in the symbol table, and by picking through the hexdump manually, I can see them too.

As far as I can see, name mangling is not at hand in the library nor my own code; the library seems to be C, and my code is too.

My goal is to be able to link to this library as it is.

Why do some tools see symbols, while others do not?

Upvotes: 1

Views: 1925

Answers (1)

S.S. Anne
S.S. Anne

Reputation: 15566

This shared object has no section header:

libXSAL.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), invalid note alignment 0x1, dynamically linked, no section header

According to the ELF standard:

Files used during linking must have a section header table; other object files may or may not have one.

You might be able to reconstruct the section header table but good luck with that.

This was done intentionally (presumably with strip) so you cannot link against the file.

Here's the option for strip that does this:

  -s --strip-all                   Remove all symbol and relocation information

Upvotes: 1

Related Questions