Question: using objdump for disassembly and inserting source code with object compiled with -gsplit-dwarf

[ISHIKAWA,chiaki]

Sorry for top posting.

The need for specifying a list of directories is for the final linked  
program.

In my case, if I recall correctly, I checked dis-assemble operation by  
objdump in the directory where the object is created (both .o and .dwo) and
so presumably objdump should be capable of finding the .dwo file from  
the information in .o file.
(The make/build process is very convoluted and so I have to investigate  
where the compilation takes place exactly.)

I will try to create a sample where gdb can list the source list, but
objdump can't mix the source line information in its disassembly.
(May take time since a very small sample source definitely works with  
objdump. Maybe a bug of g++ may have crept in somewhere. Let me  
investigate.)


Again, thank you for your attention on this matter.

Chiaki

ISHIKAWA,chiaki wrote:
> Dear Nick,
>
> Sorry for my tardy response.
> The mail got buried in other mails and I was tied up with my day job :-(
>
> Nick Clifton wrote:
>> Hi chiaki,
>>
>>> 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?
>>
>> No.
>
> 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
> the problem.
>
> 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.
> source /NREF-COMM-CENTRAL/work-dir/d.dirs
> and
> /NREF-COMM-CENTRAL/work-dir/d.dirs contains the following line:
> set debug-file-directory
> /usr/lib/debug:/other-directories-separated-by-colon-and-not-ending-in-colon
>
>
> 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
> -G list-of-directories-separated-by-colon
> 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
> the problem.
>
> TIA
>
>> Cheers
>>   Nick
>>
>
> Chiaki
>
>
>