https://sourceware.org/bugzilla/show_bug.cgi?id=29075
--- Comment #19 from Aaron Merey <amerey at redhat dot com> --- (In reply to Nick Clifton from comment #18) > > and try to keep any additional debuginfod support > > contained in objdump. > > That would be my preference too. If possible it might be best to put most of > the new code into binutils/dwarf.c since that is turning into a sort of > bfd-free library for the DWARF needs of the binutils tools. So any > improvements > might help other tools like readelf or addr2line. Hi Nick, I've been experimenting with trying to get things working using just the existing call to bfd_find_nearest_line_discriminator in objdump.c. 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. In this case the bfd library tries to reopen this file in read_alt_indirect_stirng and read_alt_indirect_ref but fails to find it since it isn't aware of debuginfod. 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. 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. WDYT? -- You are receiving this mail because: You are on the CC list for the bug.
