[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