Hi All ,
We have a scenario in our debugger to handle the file index in the
debug_ine info like
$llvm-dwarfdump -debug-line test.o
file_names[ 1]:
name: "test.cpp"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
file_names[ 2]:
name: "test.cpp"
dir_index: 1
mod_time: 0x00000000
length: 0x00000000
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000 12 0 1 0 0 is_stmt
0x0000000000000008 13 1 1 0 0 is_stmt
prologue_end
0x0000000000000010 16 0 1 0 0 is_stmt
0x0000000000000018 17 1 1 0 0 is_stmt
prologue_end
0x0000000000000020 20 0 1 0 0 is_stmt
0x0000000000000028 21 9 1 0 0 is_stmt
prologue_end
0x000000000000002f 22 9 1 0 0 is_stmt
0x0000000000000032 22 10 1 0 0
0x0000000000000035 22 7 1 0 0
0x000000000000003c 23 1 1 0 0 is_stmt
0x0000000000000040 25 0 1 0 0 is_stmt
0x0000000000000044 25 13 1 0 0 is_stmt
prologue_end
0x0000000000000080 0 0 2 0 0 is_stmt
0x000000000000008b 0 0 2 0 0 is_stmt
end_sequence
the debug info is emitted by the DIBuilder like
!3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory:
"/folk/tmp/test")
!45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp",
scope:
!3, file: !3, type: !46, flags: DIFlagArtificial, spFlags:
DISPFlagLocalToUnit | DISPFlagDefinition, unit: !2, retainedNodes: !4)
!8 = !DIFile(filename: "test.cpp", directory:
"/folk/tmp/test")
!16 = !DISubprogram(name: "proc", linkageName:
"_ZN4test4procEv", scope:
!9, file: !8, line: 8, type: !12, scopeLine: 8, flags: DIFlagPublic |
DIFlagPrototyped, spFlags: 0)
Latest clang trunk used like
$clang -std=c++14 -g -eimit-llvm -S /folk/tmp/test/test.cpp
and the respective files like test.cc ,test.ll and test.s are attached in
the mail for the reference.
the scenario is that why the file-name 's are different is both cases
,where "ZN4test4procEv" is the user defined function and
"_GLOBAL__sub_I_test.cpp"
is generated for the static initialisation ,which leads to the two file
index like 1 and 2 for two files in the filename table ,that confuse our
debugger .
So we like to hear from experts here ,before we investigate the DIBuilder
to fix the same.
Thank you
~Umesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/edf811ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpp
Type: application/octet-stream
Size: 229 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/edf811ef/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ll
Type: application/octet-stream
Size: 8771 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/edf811ef/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 24887 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/edf811ef/attachment-0002.obj>
Tomar, Sourabh Singh via llvm-dev
2020-Sep-01 17:06 UTC
[llvm-dev] Filename's in DIBuileder
[AMD Official Use Only - Internal Distribution Only]
Didn't observed this on trunk(Using attached test.cpp): Trunk at
29ae4485950ed76faa94dabbd13bbe91d2b5c750
$clang++ -std=c++14 -g test.cpp -c -S -emit-llvm -o - | awk /DIFile/
!3 = !DIFile(filename: "test.cpp", directory: "/home/")
$ clang++ -std=c++14 -g test.cpp -c -o - | llvm-dwarfdump -debug-line -
[...]
file_names[ 1]:
name: "test.cpp"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
[...]
Did I missed something, while reproducing ? ?
--Sourabh
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Umesh
Kalappa via llvm-dev
Sent: Tuesday, September 1, 2020 9:50 PM
To: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; cfe-dev at
lists.llvm.org Developers <cfe-dev at lists.llvm.org>
Subject: [llvm-dev] Filename's in DIBuileder
[CAUTION: External Email]
Hi All ,
We have a scenario in our debugger to handle the file index in the debug_ine
info like
$llvm-dwarfdump -debug-line test.o
file_names[ 1]:
name: "test.cpp"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
file_names[ 2]:
name: "test.cpp"
dir_index: 1
mod_time: 0x00000000
length: 0x00000000
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000 12 0 1 0 0 is_stmt
0x0000000000000008 13 1 1 0 0 is_stmt prologue_end
0x0000000000000010 16 0 1 0 0 is_stmt
0x0000000000000018 17 1 1 0 0 is_stmt prologue_end
0x0000000000000020 20 0 1 0 0 is_stmt
0x0000000000000028 21 9 1 0 0 is_stmt prologue_end
0x000000000000002f 22 9 1 0 0 is_stmt
0x0000000000000032 22 10 1 0 0
0x0000000000000035 22 7 1 0 0
0x000000000000003c 23 1 1 0 0 is_stmt
0x0000000000000040 25 0 1 0 0 is_stmt
0x0000000000000044 25 13 1 0 0 is_stmt prologue_end
0x0000000000000080 0 0 2 0 0 is_stmt
0x000000000000008b 0 0 2 0 0 is_stmt end_sequence
the debug info is emitted by the DIBuilder like
!3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory:
"/folk/tmp/test")
!45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp",
scope: !3, file: !3, type: !46, flags: DIFlagArtificial, spFlags:
DISPFlagLocalToUnit | DISPFlagDefinition, unit: !2, retainedNodes: !4)
!8 = !DIFile(filename: "test.cpp", directory:
"/folk/tmp/test")
!16 = !DISubprogram(name: "proc", linkageName:
"_ZN4test4procEv", scope: !9, file: !8, line: 8, type: !12, scopeLine:
8, flags: DIFlagPublic | DIFlagPrototyped, spFlags: 0)
Latest clang trunk used like
$clang -std=c++14 -g -eimit-llvm -S /folk/tmp/test/test.cpp
and the respective files like test.cc ,test.ll and test.s are attached in the
mail for the reference.
the scenario is that why the file-name 's are different is both cases
,where "ZN4test4procEv" is the user defined function and
"_GLOBAL__sub_I_test.cpp"
is generated for the static initialisation ,which leads to the two file index
like 1 and 2 for two files in the filename table ,that confuse our debugger .
So we like to hear from experts here ,before we investigate the DIBuilder to
fix the same.
Thank you
~Umesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/99c9fe4f/attachment.html>
Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate
DIFile entries, but not yet able to reproduce a .debug_line section with
multiple directory entries.
--paulr
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar,
Sourabh Singh via llvm-dev
Sent: Tuesday, September 1, 2020 1:07 PM
To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at lists.llvm.org
Developers <cfe-dev at lists.llvm.org>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Filename's in DIBuileder
[AMD Official Use Only - Internal Distribution Only]
Didn't observed this on trunk(Using attached test.cpp): Trunk at
29ae4485950ed76faa94dabbd13bbe91d2b5c750
$clang++ -std=c++14 -g test.cpp -c -S -emit-llvm -o - | awk /DIFile/
!3 = !DIFile(filename: "test.cpp", directory: "/home/")
$ clang++ -std=c++14 -g test.cpp -c -o - | llvm-dwarfdump -debug-line -
[...]
file_names[ 1]:
name: "test.cpp"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
[...]
Did I missed something, while reproducing ? ?
--Sourabh
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Umesh Kalappa via llvm-dev
Sent: Tuesday, September 1, 2020 9:50 PM
To: LLVM Developers Mailing List <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org> Developers <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: [llvm-dev] Filename's in DIBuileder
[CAUTION: External Email]
Hi All ,
We have a scenario in our debugger to handle the file index in the debug_ine
info like
$llvm-dwarfdump -debug-line test.o
file_names[ 1]:
name: "test.cpp"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
file_names[ 2]:
name: "test.cpp"
dir_index: 1
mod_time: 0x00000000
length: 0x00000000
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000 12 0 1 0 0 is_stmt
0x0000000000000008 13 1 1 0 0 is_stmt prologue_end
0x0000000000000010 16 0 1 0 0 is_stmt
0x0000000000000018 17 1 1 0 0 is_stmt prologue_end
0x0000000000000020 20 0 1 0 0 is_stmt
0x0000000000000028 21 9 1 0 0 is_stmt prologue_end
0x000000000000002f 22 9 1 0 0 is_stmt
0x0000000000000032 22 10 1 0 0
0x0000000000000035 22 7 1 0 0
0x000000000000003c 23 1 1 0 0 is_stmt
0x0000000000000040 25 0 1 0 0 is_stmt
0x0000000000000044 25 13 1 0 0 is_stmt prologue_end
0x0000000000000080 0 0 2 0 0 is_stmt
0x000000000000008b 0 0 2 0 0 is_stmt end_sequence
the debug info is emitted by the DIBuilder like
!3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory:
"/folk/tmp/test")
!45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp",
scope: !3, file: !3, type: !46, flags: DIFlagArtificial, spFlags:
DISPFlagLocalToUnit | DISPFlagDefinition, unit: !2, retainedNodes: !4)
!8 = !DIFile(filename: "test.cpp", directory:
"/folk/tmp/test")
!16 = !DISubprogram(name: "proc", linkageName:
"_ZN4test4procEv", scope: !9, file: !8, line: 8, type: !12, scopeLine:
8, flags: DIFlagPublic | DIFlagPrototyped, spFlags: 0)
Latest clang trunk used like
$clang -std=c++14 -g -eimit-llvm -S /folk/tmp/test/test.cpp
and the respective files like test.cc ,test.ll and test.s are attached in the
mail for the reference.
the scenario is that why the file-name 's are different is both cases
,where "ZN4test4procEv" is the user defined function and
"_GLOBAL__sub_I_test.cpp"
is generated for the static initialisation ,which leads to the two file index
like 1 and 2 for two files in the filename table ,that confuse our debugger .
So we like to hear from experts here ,before we investigate the DIBuilder to
fix the same.
Thank you
~Umesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/3dc48f73/attachment.html>