This is certainly not a high-priority request, as you can tell from how long it's sat untended in bugzilla. So you can decide whether this is what you should spend time on. But, I don't think it's necessarily hard to do, and it might be a good way to understand the interfaces better.
It is indeed the plan to decode the .hash and/or .gnu.hash data (found via DT_* pointers, not section headers) and print only the .dynsym entries (again, found via DT_SYMTAB) pointed to by hash buckets, in hash table order. You do need to decode the hash bucket/chain format to find which symtab entries are used and in what order. That is the real decoding work. Extracting the symtab data is straightforward because you can just use gelf_getdata_rawchunk with ELF_T_SYM. The only sticky part there is that nothing actually tells you the total size of the symbol table, only the size of an individual entry (DT_SYMENT). So you have to do some guesswork to decide how big you think the table is. There is some code in libdwfl/core-file.c that does this guessing, which IIRC amounts to just deciding that DT_STRTAB will follow DT_SYMTAB and using it as the upper bound. But I'm not entirely sure that heuristic wins for all cases in practice, when prelink might move .dynsym around to be elsewhere. You'll have to poke at a few different real-world binaries, including prelinked ones, so see what the constraints are. Another tack you can take is not to try to figure out the real bounds, but just figure out what you need. That is probably the most clever thing to do for this case. From decoding the hash tables, you'll know the highest symtab index you will need to read. Multiply that+1 by the DT_SYMENT value, and you have the total size you need for elf_getdata_rawchunk. Thanks, Roland _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
