[Ltrace-devel] Getting prototypes from debug information

[Dima Kogan]

Petr Machata <pmachata at redhat.com> writes:

> Mark Wielaard <mjw at redhat.com> writes:
>
>> On Mon, 2014-05-12 at 16:36 +0200, Petr Machata wrote:
>>> I see it now.  So correct me if I'm wrong, but that means that after the
>>> first dwfl_report_elf, dwfl_nextcu would iterate over just that one
>>> module. However after second dwfl_report_elf, dwfl_nextcu would again
>>> iterate over the first module, as well as the second module.
>>> 
>>> If that's correct, then I believe what we should store at struct library
>>> is Dwfl_Module, not Dwfl itself.
>>
>> Yes, that seems correct. dwfl_report_elf does report the Dwfl_Module (or
>> NULL on failure). So you can use that and dwfl_module_nextcu.
>
> Dima, I think you should be able to verify whether the second
> dwfl_nextcu iterates over the first module's data as well.  While that's
> probably harmless, it's a work duplication, and a better design would be
> to store Dwfl_Module at struct library and use dwfl_module_nextcu as
> indicated above.

Hi. I'll confess to not fully grokking what libdwfl does, as that
library is not encumbered by any documentation. For testing I added a
bit of diagnosting output right after the dwfl_nextcu() call, so that
snippet looks like

  while ((die = dwfl_nextcu(dwfl, die, &bias)) != NULL) {
          fprintf(stderr, "Looking at cu %s at %x\n",
                  dwarf_diename(die), dwarf_dieoffset(die));

I then did some ltrace runs, filtering the output through

 grep 'Looking at' | sort | uniq -d

in order to see the same compile unit being processed more than once. I
did this with the same simple test program as before that calls usleep()
and nanosleep(). I tried with both -x and -l, and

   no duplicate CUs are being processed in either case.

Is this a sufficient test? Do I need to test more complicated
conditions?

dima