support for ELF relocatable objects (i.e. Linux kernel modules)

As seen in the following code:

https://github.com/angr/cle/blob/82e33f92e18d7b5a8cfb9ed43663d50a52a4ab43/cle/backends/elf.py#L491

The ELF backend uses sh_addr for loading objects into the memory; however, for relocatable objects the sh_addr is always zero (only sh_offset is set). This causes the binary loading to fail.

[iamahuman]

How about looking up symbols internally not only by name but with a tuple containing all attributes (name (of course), section index, address, visibility, …) of that symbol, and have a new public method get_symbols that, when given a name (possibly with an option that filters only global ones), returns list of all matching symbols? That way it could not only address section symbol issue, but also could handle some uncommon edge cases that are still work find in real-world OSes anyway.

[iamahuman]

I think I figured out a way to distinguish how the symbols can be resolved.

   st_other  This member defines the symbol visibility.

             STV_DEFAULT     Default symbol visibility rules.  Global
                             and weak symbols are available to other
                             modules; references in the local module can
                             be interposed by definitions in other
                             modules.
             STV_INTERNAL    Processor-specific hidden class.
             STV_HIDDEN      Symbol is unavailable to other modules;
                             references in the local module always
                             resolve to the local symbol (i.e., the
                             symbol can't be interposed by definitions
                             in other modules).
             STV_PROTECTED   Symbol is available to other modules, but
                             references in the local module always
                             resolve to the local symbol.

Please excuse my previous comment, for it seems obvious how to determine whether a symbol is local or global. In this case, my question about prepending ## would not make much sense here.

EDIT: section symbols appear to be STV_DEFAULT, needs more research.

EDIT 2: If sh_info is an integer or is 'SHN_ABS', it means it is already resolved and need not be resolved furthur. It is thus safe to let it be resolved by itself.

EDIT 3: .dynsym and .symtab seem to use the same _symbol_cache, is it safe to assume these two don’t collide? The current symbol lookup—which uses the name as the sole identifier—is prone to special symbols with an empty name (e.g. section symbols). Changing it to use indexes as cache however may introduce collisions.

If .dynsym and .symtab do coexist, then I wonder what should be used to uniquely identify symbols? Names are not unique (yes they are supposed to be unique if not empty as specified in the docs, but even with duplicate names some loaders could handle them), and indexes are only meaningful if its container table is provided. Creating a tuple as in #24 seems to work, but the key too is not guaranteed to be unique and it’s a bit slow.

I might have grasped a dim idea as to how they are supposed to work, but the exact mechanism remains unclear. I hope I have some luck finding relevant info in GNU binutils source code.

EDIT 4: It’s the sh_link member that (for relocation tables) specify which symtab the table is using. The CLE code for MIPS64 seems a little off here, though.