[Ltrace-devel] DWARF prototypes: handling symbol aliases

Dima Kogan lists at dima.secretsauce.net
Fri Jul 11 00:08:34 UTC 2014


Petr Machata <pmachata at redhat.com> writes:

> Dima Kogan <lists at dima.secretsauce.net> writes:
>
>>> We could actually store vectors in the hash table directly.
>>
>> The reason I did it this way was to reduce the memory inefficiency of
>> the hash table. [...] Still want this change?
>
> That's a good point.  I'm not decided one way or another, so let's keep
> it the way you wrote it.

ok

>> In any case, the patch seems to work, but I'd be more comfortable if the
>> test suite told me it was good. I see the same test/suite failures
>> before and after, some non-deterministic. Do you know which tests
>> specifically are good to look at for a change like this?
>
> There are two tests in filters.exp that test specifically the -l stuff,
> i.e. this sort of export list handling thing.

OK. That test passes. I really should write a test for the DWARF code.
I'll do that when I finish tying the loose ends.


> Non-determinism in ltrace has always been a problem.  It used to be much
> worse, but there might still be latent bugs, or bugs that the kernels
> other than those that I test on expose.  What's you configuration, and
> what failures are you seeing?

I didn't take good notes, so this is incomplete, sorry. I was seeing the
trace-irelative.exp test get into an infinite loop. ltrace was running
until I killed it. The ltrace command was

 ./ltrace -L -x xyz /tmp/pie-yjtNlTxFte

Running that same command with that same executable later worked just
fine. There was some log file that was being generated that had 200MB of
the same error repeated on every line. Something about an illegal or
duplicated breakpoint; don't exactly remember, sorry. Re-running the
test suite didn't show this problem.

By the way, how much of the suite is supposed to pass normally? I always
see some failures and a segfault. The configuration is Debian/sid on
amd64; nothing noteworthy.


> OK, so I tried to merge and do a test build, and am now getting this:
>
> <errors>

I just pushed a patch. You were using an older gcc than me, and it's
more picky. Before this patch I successfully tested with gcc 4.9. After,
gcc 4.6 works too.


I also just discovered that this new symbol aliasing code works with
'ltrace -l', but not any of the other filtering options. I'll take a
look when i have time; hopefully by next week.

dima



More information about the Ltrace-devel mailing list