[Ltrace-devel] Getting prototypes from debug information

[Petr Machata]

Dima Kogan <lists at dima.secretsauce.net> writes:

> Petr Machata <pmachata at redhat.com> writes:
>
>> 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.
>
>    no duplicate CUs are being processed in either case.

I understand what's happening.  In proc.c, you look at
proc->leader->dwfl, and use that if it's present.  If it's not, you
create a new one.  But then you only store it at lib->dwfl, never at
proc->leader->dwfl.  Only when -w is active is proc->leader->dwfl
actually initialized, in which case the duplication scenario does occur.

So:

- proc->leader->dwfl should be initialized always, not only for bt_depth>0.

- whether dwfl_linux_proc_attach needs initialization, or what the
  result of that initialization was, needs a separate flag, stored at
  struct process, it seems to me.  Currectly it uses proc->leader->dwfl
  != NULL to determine whether it should try to initialize, so in the
  extreme, it might try to reinitialize on every library add, which
  probably isn't useful.  On contrary, even though we couldn't
  initialize backtraces, we might still be able to use the corresponding
  debuginfos, so dwfl != NULL is not the right test here.

- struct library should carry Dwfl_Module (what dwfl_report_elf returns)
  and in dwarf_prototypes.c, we should iterate it using
  dwfl_module_nextcu.

Makes sense?

Thanks,
PM