[RFC] libdw: prepend current directory in read_srclines
Hi, I observed that readelf and elfutils sometimes report different results. PFA a patch that corrects this. I’m not sure whether the way I tackled the problem is acceptable. Kind Regards, Torsten 0001-libdw-prepend-current-directory-in-read_srclines.patch Description: Binary data
Re: [RFC] libdw: prepend current directory in read_srclines
Hi Mark, > Am 27.03.2017 um 22:45 schrieb Mark Wielaard : > > Hi Torsten, > > On Sun, Mar 26, 2017 at 08:35:50PM +0200, Torsten Polle wrote: >> I observed that readelf and elfutils sometimes report different results. > > Do you have an example of this? It would be good to have a testcase. > >> PFA a patch that corrects this. I’m not sure whether the way I tackled >> the problem is acceptable. > > I see why you are proposing this. The DWARF spec does say about the > include_directories "Each path entry is either a full path name or is > relative to the current directory of the compilation". So your patch > does make sense. > > But it does depend on what users of dwarf_getsrclines expect. > Or any use of Dwarf_Line/Dwarf_Files. I think those users expect that > the returned file names can be relative. And that they should make them > absolute using index zero or the comp_dir themselves. > > So if you do have an example where the expected output isn't what you > believe it should be we should examine if there is some other way to > do the right thing. > > Cheers, > Mark thanks for the answer. I’ll come back with an example, which is SystemTap based. :-) Please allow for some delay. I expect to provide an example in about two weeks. Regards, Torsten
Re: [RFC] libdw: prepend current directory in read_srclines
Hi Mark,
> Am 29.03.2017 um 22:15 schrieb Torsten Polle :
>
> Hi Mark,
>
>> Am 27.03.2017 um 22:45 schrieb Mark Wielaard :
>>
>> Hi Torsten,
>>
>> On Sun, Mar 26, 2017 at 08:35:50PM +0200, Torsten Polle wrote:
>>> I observed that readelf and elfutils sometimes report different results.
>>
>> Do you have an example of this? It would be good to have a testcase.
>>
>>> PFA a patch that corrects this. I’m not sure whether the way I tackled
>>> the problem is acceptable.
>>
>> I see why you are proposing this. The DWARF spec does say about the
>> include_directories "Each path entry is either a full path name or is
>> relative to the current directory of the compilation". So your patch
>> does make sense.
>>
>> But it does depend on what users of dwarf_getsrclines expect.
>> Or any use of Dwarf_Line/Dwarf_Files. I think those users expect that
>> the returned file names can be relative. And that they should make them
>> absolute using index zero or the comp_dir themselves.
>>
>> So if you do have an example where the expected output isn't what you
>> believe it should be we should examine if there is some other way to
>> do the right thing.
>>
>> Cheers,
>> Mark
>
> thanks for the answer. I’ll come back with an example, which is SystemTap
> based. :-)
>
> Please allow for some delay. I expect to provide an example in about two
> weeks.
>
> Regards,
> Torsten
Sorry for coming back so late. Please find attached my reproduction.
I compile the simple program relative.c:
int main()
{
return 0;
}
with the command "gcc -g ../2017-05-03-elfutils/relative.c -o relative“.
When I run systemtap with the command
/opt/tooling/adit/systemtap/bin/stap -g -a i386 -B
CROSS_COMPILE=i586-poky-linux- -r
/home/polle/work/build/poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.8.12+gitAUTOINC+926c93ae07_021b4aef55-r0/build
--sysroot=/home/polle/work/build/poky/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/rootfs
-L 'process("/bin/relative").function("main").call‘
I get the following output:
process("/bin/relative").function("main@../2017-05-03-elfutils/relative.c:1").call
But running nm returns the following.
nm -l | grep relative
080483eb T main
/home/polle/work/issues/2017-05-03-elfutils/../2017-05-03-elfutils/relative.c:1
I hope this helps.
Kind Regards,
Torsten
Re: Relative path X full path
Hi Sasha, > Am 26.03.2018 um 18:45 schrieb Sasha Da Rocha Pinheiro > : > > Hi, > > I have noticed that when we compile out-of-source, the paths returned from > libdw are gonna be relative. Otherwise, they show up as full path. > Have you noticed it? > > Regards, > Sasha this is the issue that was discussed in [1] and [2]. Kind Regards, Torsten [1] https://sourceware.org/ml/elfutils-devel/2017-q1/msg00117.html [2] https://sourceware.org/ml/elfutils-devel/2017-q2/msg00148.html
Re: Read .debug_line without .debug_info
Hi Mark, > Am 26.03.2018 um 21:12 schrieb Mark Wielaard : > > Hi Sasha, > > On Mon, Mar 26, 2018 at 04:41:06PM +, Sasha Da Rocha Pinheiro wrote: >> is it possible to read contents of .debug_line section without the >> presence of a .debug_info section? > > No, because .debug_line sections need some information from the CU > which comes from the .debug_info. In particular the directory table > starts with the compilation directory which can only be gotten from > the CU (DW_AT_comp_dir). The files in the file list (which don't have > an explicit dir associated) are all given relative to that comp dir. you could take this information from the include directories: "11. include_directories (sequence of path names) Entries in this sequence describe each path that was searched for included source files in this compilation. (The paths include those directories specified explicitly by the user for the compiler to search and those the compiler searches without explicit direction.) Each path entry is either a full path name or is relative to the current directory of the compilation. The last entry is followed by a single null byte. The line number program assigns numbers to each of the file entries in order, beginning with 1. The current directory of the compilation is understood to be the zeroth entry and is not explicitly represented." Kind Regards, Torsten
