bug-binutils
[Top][All Lists]
Advanced

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

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


From: amerey at redhat dot com
Subject: [Bug binutils/29075] objdump -S does not support debuginfod
Date: Fri, 19 Aug 2022 00:11:27 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29075

--- Comment #21 from Aaron Merey <amerey at redhat dot com> ---
(In reply to Nick Clifton from comment #20)
> (In reply to Aaron Merey from comment #19)
> > 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 ?

The more generic function you suggested below should be able to deal with
those. One of the bfd parameters would represent the debuglink file and the
second would represent either the debugaltlink or debug_sup file. Presumably no
binary would contain both 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.

Most of the changes would be to libbfd itself. Essentially I want to pass an
additional bfd* to _bfd_dwarf2_find_nearest_line in order to set the
stash->alt.bfd_ptr. If this ptr is set we avoid a failed search for the alt
file.

We can keep the existing bfd_find_nearest_line API stable by having it always
pass NULL to _bfd_dwarf2_find_nearest_line in place of this argument. However
I'd like to avoid having to implement a version of bfd_find_nearest_line_2 for
each bfd target. What do you think about simply exposing this new function in
bfd/elf-bfd.h for objdump.c to call directly?

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