[Ltrace-devel] DWARF prototypes: handling symbol aliases
Dima Kogan
lists at dima.secretsauce.net
Mon Jun 2 09:53:02 UTC 2014
Petr Machata <pmachata at redhat.com> writes:
> Dima Kogan <lists at dima.secretsauce.net> writes:
>
>> Hi. This code wasn't pushed anywhere, but if you want to look at it,
>> it's here:
>>
>> https://github.com/dkogan/ltrace/tree/libsym_aliases_inexportlist
>
> The approach seems reasonable to me.
Hi.
I took a pass through the code. It's now of candidate-mergeable quality.
As before, the tree appears in
https://github.com/dkogan/ltrace/tree/libsym_aliases_inexportlist
As usual, some comments and things that may need fixing before this is
pushed:
1. I added a integer hash function for uint64_t keys, but kept the math
the same as that for the 32-bit keys. Computing an appropriate constant
is easy, I just haven't done it yet.
2. The name is still "exported_names". As before, this is
unconditionally filled in. Again, as before, there's a "symbols" field
that IS populated conditionally, and generally has way more "stuff" in
it. These two fields can be merged, but I haven't attempted that. I
can't think of a better name than "exported_names".
"exported_names_addrs" ?
3. The data structure currently is not ideally efficient. I'm using two
dicts. One to map symbol names -> addrs. And another to map an addr ->
vect(symbol names). This is fine for lookups (I'm assuming the memory
usage is reasonable), but is poor for iteration, which we need for
activate_latent_in(). How bad is it? Ideally one of the hashes would be
a tree of some sort, but there's no such structure in ltrace. I can also
add a 3rd structure that's a linked list used just for this iteration.
I'm tempted to just leave it as is.
4. I discovered that in the libc on my machine (Debian/sid amd64) some
symbols appear at multiple addresses:
dima at shorty:~/projects/ltrace$ nm -D /lib/x86_64-linux-gnu/libc-2.18.so | awk '{print $NF}' | sort | uniq -d
_sys_errlist
_sys_nerr
_sys_siglist
memcpy
nftw
nftw64
posix_spawn
posix_spawnp
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
realpath
regexec
sched_getaffinity
sched_setaffinity
sys_errlist
sys_nerr
sys_sigabbrev
sys_siglist
Those are versioned symbols, with different implementation for different
libc versions. This same-symbol-different-address idea doesn't fit into
the data structures, as I've currently defined them. I explicitly ignore
any such repetitions to avoid printing out useless errors. Again, I'm
tempted to leave it as is, since there just aren't many of such
functions, and it doesn't sound worth it to me to deal with it.
OK. Let me know if there are issues in the implementation, or if any of
these are show-stoppers.
Thanks!
dima
More information about the Ltrace-devel
mailing list