[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
