[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/29075] objdump -S does not support debuginfod

From: nickc at redhat dot com
Subject: [Bug binutils/29075] objdump -S does not support debuginfod
Date: Thu, 18 Aug 2022 10:48:18 +0000


--- 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.


You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]