Dima Kogan <[email protected]> writes: > Petr Machata <[email protected]> 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
