https://sourceware.org/bugzilla/show_bug.cgi?id=29075
Aaron Merey <amerey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|nickc at redhat dot com |amerey at redhat dot com
CC| |amerey at redhat dot com
--- Comment #17 from Aaron Merey <amerey at redhat dot com> ---
(In reply to Nick Clifton from comment #15)
> The other issue is finding the time to actually write this code. If someone
> is volunteering then I would be very happy to leave it to them ... :-)
I'll take a look at this and try to keep any additional debuginfod support
contained in objdump.
(In reply to Frank Ch. Eigler from comment #16)
> (OTOH bfd/opencls.c has debuginfod-analogous lookup (hard-coding the
> /usr/lib/.build-id/XXX convention). It could fall back to a debuginfod
> query via spawning an external debuginfod-find process, if the
> EXTRA_DEBUG_ROOT1 searches fail. Any idea why we thought putting the code
> into binutils/dwarf.c instead was the right place for the hook?)
Despite using BFD, objdump and GDB implement their own procedures for finding
and loading separate debuginfo so tool-specific debuginfod clients were needed
in these cases. This doesn't mean that BFD should not also include debuginfod
support but until now there didn't appear to be much need for it.
--
You are receiving this mail because:
You are on the CC list for the bug.
