https://sourceware.org/bugzilla/show_bug.cgi?id=29075
--- Comment #30 from Aaron Merey <amerey at redhat dot com> --- (In reply to Martin Liska from comment #29) > Thanks for the implementation. However, I think one piece is missing and it's > find_separate_debug and find_separate_debug rely on fact the debugginfo is > present for a abfd, but can't load it from debuginfod: > > $ DEBUGINFOD_VERBOSE=1 > /home/marxin/Programming/binutils/objdir/binutils/objdump -S `which true` > (does not get any source file) > > while installing coreutils-debuginfo (and *not* coreutils-debugsource) I get: > > $ DEBUGINFOD_VERBOSE=1 > /home/marxin/Programming/binutils/objdir/binutils/objdump -S `which true` [...] > char const *node = program; > struct infomap const *map_prog = infomap; > 249c: 48 89 e3 mov %rsp,%rbx It looks like this happens because of some peculiarities regarding how objdump and libbfd handle the default settings for following debug links. For the case where coreutils-debuginfo is not installed: if you explicitly tell objdump to process links with the '-L' option then debuginfod is used to download the missing debuginfo as expected. If '-L' is not given then objdump is configured to not attempt to look for any separate debuginfo unless '--dwarf=follow-links' is given without being enabled by default or '--dwarf=follow-links' is enabled by default AND objdump is given a command line option that requires the use of debuginfo like '--debugging'. Currently '-S' is not taken to be such an option. So 'objdump -S' does not bother to check for separate debuginfo unless one of these other conditions met. Consequently objdump will not have the information needed to download any source files either. So why does 'objdump -S' download source files when coreutils-debuginfo is installed? Objdump itself does not look for the debuginfo in this case, as it follows the same logic I described above. Instead the search for the debuginfo occurs within libbfd. It does this on its own terms, even if you run 'objdump -S --dwarf=no-follow-links' libbfd still searches for the separate debuginfo file (maybe this is a bug?). If libbfd can find the debuginfo, it passes line information back to objdump which it uses to download any missing source files. The simplest way to address this is probably to modify the behavior of '-S' so that it enables the processing of debuglinks when '--dwarf=follow-links' is enabled, without requiring any additional conditions to be met. However this will not stop libbfd from finding locally-installed debuginfo even when you tell objdump to not follow links. -- You are receiving this mail because: You are on the CC list for the bug.
