This is the mail archive of the
mailing list for the binutils project.
Re: Question: using objdump for disassembly and inserting source code with object compiled with -gsplit-dwarf
- From: "ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>
- To: Nick Clifton <nickc at redhat dot com>, Binutils <binutils at sourceware dot org>
- Date: Thu, 30 Jun 2016 12:07:59 +0900
- Subject: Re: Question: using objdump for disassembly and inserting source code with object compiled with -gsplit-dwarf
- Authentication-results: sourceware.org; auth=none
- Authentication-results: access07.SiriusCloud.jp; dkim=none (no signature) header.i=unknown; x-dkim-adsp=none (insecure policy)
- References: <a9e39097-1e6d-ba92-c350-6a69820fa931 at yk dot rim dot or dot jp> <c554e6aa-2247-5980-ecb1-0981c07b7683 at redhat dot com>
Sorry for my tardy response.
The mail got buried in other mails and I was tied up with my day job :-(
Nick Clifton wrote:
However, for a medium size c++ file, I found that the source inclusion is not very good. The function signature is inserted, but no source code lines somehow.
Is this to be expected?
I see. Then I think I am seeing a bug.
Or is there a known bug with objdump?
It is a bug, but not a known one. Please could you open a bugzilla report
for the problem, along with, if possible, a small(ish) test case that
reproduces the problem.
I will try, but not sure if I will succeed in a reasonable amount of time.
It is possible that gcc 5.3 or 6.1 may not be producing correct DWARF
in .o and .dwp which objdump can grok
This is entirely possible. But if so, then it still may be possible to
have objdump warn the user that the debug info is broken/incomplete/missing.
Right. binutils programs ought to warn the user if they encounter
unexpected data format.
As an aside - is GDB able to produce correct source+disassembly listings
from the same input file(s) ? If so then this would point more towards
objdump being at fault. If not then it may well be a G++ problem.
GDB definitely can print the source line, etc.
However, there is a catch. And I am afraid that it could be the cause of
GDB has a feature that lets us tell where gdb should try to find the
.dwo file (the external auxiliary debug information file aside from the
.o file itself).
Specifically, "set debug-file-directory" command is used to list the
directories where gdb ought to look for the related .dwo files.
The said medium-sized program is linked from object files from various
directories and thus we need to tell GDB the directories where to look
for the .dwo files.
E.g.: from my .gdbinit file:
# Path for looking for .dwo files.
/NREF-COMM-CENTRAL/work-dir/d.dirs contains the following line:
Now, I am not sure. Come to think of it, the source file and line number
is very likely to be in .o file and .dwo file contains additional data
type information, etc.
(Aha, now I see. the source file information in .o file is
only relative to the compilation directory, i.e. where the compilation
takes place, and thus GDB needs to know the full pathname from the side
channel?: that is what set debug-file-directory does (?).)
If my guess is correct, then
this suggests that objdump (and friends) may need to take an optional
argument something like
to tell it where to look for .dwo files.
Anyway, I will try to see if I can create a smallish file to re-create