Question

I’ve opened a shread library with lt_dlopen and would like to search the list of exported symbols for those matching a specific pattern (the name of the function matches the pattern).

Is there any simple way to do this? Either search by pattern, or just get a list of all exported named. By simple I mean without a special library just for loading symbols.

The main program and library is C++ but all symbols will be extern "C".

Answer 1

You can follow the recipe outlined in this article just that, if you’re accessing symbols within our own address space / from a library you loaded via dlopen() is much simpler:

1. The “struct link_map*” you obtain by reinterpret_cast<struct link_map*>(dlopen(...)); – so no need to parse “your own ELF”. See the sourcecode for __dlopen().
2. You don’t need to use ptrace() to read from your own address space – just cast the pointers directly.

I’ll illustrate the 2nd for finding the symbol table address:

struct link_map *map = reinterpret_cast<struct link_map*>(dlopen(...));
int nchains = 0;
Elf32_Dyn *dyn = static_cast<Elf32_Dyn*>(map->l_ld);
Elf32_Sym *symtab = NULL;
char *strtab = NULL;

while (dyn->d_tag) {
    switch (dyn->d_tag) {
    case DT_HASH:
        nchains = *static_cast<int*>(dyn->d_un.d_ptr + map->l_addr + 4);
        break;
    case DT_SYM:
        symtab = static_cast<Elf32_Sym*>(dyn->d_un.d_ptr);
        break;
    case DT_STR:
        strtab = static_cast<char*>(dyn->d_un.d_ptr);
        break;
    default:
        break;
    }
    dyn++;
}

This is an in-memory equivalent of the resolv_tables() function in the article I linked to. Converting the find_sym_in_tables() to a pattern-search through your own address space is left as an exercise to the reader.

Note that this is Linux-specific (dlopen() returning a struct link_map*). For other systems, the technique should work as long as this condition is met (and they’re using ELF).

Edit: This is for 32bit ELF; if you’re using 64bit, data types change (Elf64_Sym / Elf64_Dyn and 64bit integers for the table size I think). I’m sure this can be abstracted (the glibc sources do so …), it just doesn’t make the code easy to read anymore. Again, I leave it as exercise to the reader.