Date: Sun, 19 Aug 2012 18:42:30 +0200 From: musl <b.brezillon.musl@...il.com> To: musl@...ts.openwall.com Subject: Re: ldso : dladdr support Hi, This patch fixes a bug in dladdr: sym var was not incremented across gnu hash chain iteration). I also reworked the dladdr implem to share more code between sysv and gnu hash. I still haven't found a better way to get the symbol table size. Do you? This patch uses the new decode_vec function, but as I told you in my previous mail, I'm not sure this the way to go. Could you tell me what you think? On 17/08/2012 07:39, Rich Felker wrote: > On Thu, Aug 16, 2012 at 12:41:48AM +0200, boris brezillon wrote: >>> Sorry for taking a while to get back to you. I haven't had as much >>> time to work on musl the past couple weeks and some other topics (like >>> mips dynamic linking) had priority, but I hope to have more again for >>> a while now. Here's a quick review of some things that will hopefully >>> turn into a discussion for improving/simplifying the code. >> No problem. >> Thanks for the review. >> Do you want to discuss it on irc or keep going on the mailing list? > List is best I think, but I don't mind having some specific > discussions that need more real-time feedback on IRC. > >>> BTW, while I _want_ it to be safe, it's possible that early switches >>> (early meaning prior to the comment in __dynlink that says libc is now >>> fully functional) will actually fail to work/crash on some archs... So >>> this needs consideration too. >>> >> I didn't knew that. Could explain me why? > The compiler may compile a switch to something like: > > jmp *local_jmptable@...OFF(%ebx,%ecx,4) > > where the local_jmptable needs to contain absolute jump addresses. > Prior to relocation, it will obly have the load-address-relative > addresses. > >>> I'm not seeing why this function needs hash tables at all. It's not >>> looking up symbols, just iterating over the entire symbol table, no? >>> Please explain if I'm mistaken. >> I don't see any other way to know the sym table size except reading >> the .dynsym section header. > Indeed, I missed the fact that there's no DT_* entry reporting the > symbol table size. I checked how readelf reports the number of > entries, and it's using the section headers. I'm under the impression > that using them would not be valid for the dynamic linker; reportedly > ELF files are supposed to be valid even with the section headers > stripped. > >> That's why I'm iterating over the hash table. >> For sysv hash the nchain (second entry of hash table) gives the sym table size. >> For gnu hash It's a little bit more complicated (see >> https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections). > Wow, leave it to the GNU folks to take something simple and make it > difficult... > >> Should we parse the .dynsym section header and store the sym table >> size in dso struct? >> Do you see any other way to get the dynsym table size or at least >> iterate over the dynsym table (specific pattern for last element ?). > I've been looking but I don't see any way yet. > > Rich View attachment "dladdr-gnu-hash-v3.patch" of type "text/x-patch" (14727 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.