https://sourceware.org/bugzilla/show_bug.cgi?id=29075
--- Comment #20 from Nick Clifton <nickc at redhat dot com> --- (In reply to Aaron Merey from comment #19) Hi Aaron, > Passing > the bfd object of the separate debuginfo instead of the bfd of the parent > file seems to work unless a .gnu_debugaltlink file exists. What about .gnu.debuglink sections ? Or .debug_sup sections ? > One solution to this that avoids adding debuginfod support to libbfd as well > as implementing a new find_nearest_line in binutils/dwarf.c is to add a > _bfd_elf_find_nearest_line_with_gnu_debugaltlink that is based on > _bfd_elf_find_nearest_line but it includes an additional bfd* parameter for > the debugaltlink file. Since the file is manually specified libbfd doesn't > have to search for it. That makes sense. I wonder if it would be better to make the new function slightly more generic however. eg: bfd_find_nearest_line_2 (bfd * binary_bfd, bfd * debug_bfd) Ie passing in a second bfd containing debug information, but the method of acquiring that debug bfd is not limited to .gnu.debugaltlink sections. > I think this solution is the simplest way to fully implement debuginfod > support for objdump -S and it can be used by addr2line and readelf as well. Simple is good. :-) If it turns out that there is a lot of common code that needs to be added to objdump, readelf and addr2line however then it might be worth considering moving it into, eg, binutils/bucomm.c. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
