* [gdb]Line number zero in line table gives incorrect debugging experince with gdb
[not found] ` <CAMyYBzwV9dr5Aue-rrrbtLRc30F==OaVih91kpzF8KpBtaqMNQ@mail.gmail.com>
@ 2020-08-27 15:02 ` Jaydeep Chauhan
2020-08-28 16:59 ` Line " Tom Tromey
0 siblings, 1 reply; 3+ messages in thread
From: Jaydeep Chauhan @ 2020-08-27 15:02 UTC (permalink / raw)
To: gdb
[-- Attachment #1: Type: text/plain, Size: 3814 bytes --]
Hi Everyone,
We have a situation with GDB(latest trunk) and below testcase
referred for further discussion :
$ cat gdb.c
1 /* demo testcase */
2 int garr[2];
3 int main() {
4
5 if((garr[0] && garr[1])==0){
6 garr[0]=1;
7 garr[1]=1;
8 }
9 else {
10 garr[0]=2;
11 garr[1]=2;
12 }
13 printf("%d %d\n",garr[0], garr[1]);
14 return 0;
15 }
$clang -target arm64 -g -c gdb.c
$./llvm-dwarfdump --debug-line gdb.o
...
...
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000 3 0 1 0 0 is_stmt
0x000000000000000c 0 0 1 0 0 is_stmt prologue_end
0x000000000000001c 5 13 1 0 0 is_stmt
0x000000000000002c 5 21 1 0 0
0x0000000000000030 0 21 1 0 0
0x0000000000000034 5 24 1 0 0
0x0000000000000038 5 21 1 0 0
0x0000000000000044 0 21 1 0 0
0x0000000000000048 5 12 1 0 0
0x000000000000004c 0 12 1 0 0
0x0000000000000054 6 24 1 0 0 is_stmt
0x000000000000005c 7 24 1 0 0 is_stmt
0x0000000000000060 8 9 1 0 0 is_stmt
0x0000000000000064 0 9 1 0 0
0x000000000000006c 10 25 1 0 0 is_stmt
0x0000000000000074 11 25 1 0 0 is_stmt
0x0000000000000078 0 0 1 0 0
0x000000000000007c 13 27 1 0 0 is_stmt
0x0000000000000084 13 36 1 0 0
0x0000000000000088 0 0 1 0 0
0x0000000000000090 13 10 1 0 0
0x0000000000000098 14 10 1 0 0 is_stmt
0x00000000000000a8 14 10 1 0 0 is_stmt end_sequence
=================================================================================================
Let’s demonstrate two issues that we see w.r.t gdb that are
related to zero line number.
1)As per above line table prologue_end is set to line zero and we set
breakpoint on function then gdb info was stated like below .
(gdb) b main
Breakpoint 1 at 0x800005ec: file gdb.c, line 0.
It should be, something like
(gdb) b main
Breakpoint 1 at 0x800005ec: file gdb.c, line 3.
2)
Breakpoint 1, main () at gdb.c:0
1 /* demo testcase */
(gdb) n
5 if((garr[0] && garr[1])==0){
(gdb)
1 /* demo testcase */
(gdb)
5 if((garr[0] && garr[1])==0){
(gdb)
1 /* demo testcase */
(gdb)
6 garr[0]=1;
(gdb)
7 garr[1]=1;
(gdb)
8 }
(gdb)
1 /* demo testcase */
(gdb)
13 printf("%d %d\n",garr[0], garr[1]);
(gdb)
1 /* demo testcase */
(gdb)
13 printf("%d %d\n",garr[0], garr[1]);
(gdb)
1 1
14 return 0;
(gdb)
Here the sequence like “5->1->5->6” should be “5->5->6” and as per
DWARF standard ,ZERO line has a well-defined meaning and stands for
"no source line corresponds to this location".
From LLVM point of view the ZERO-LINE debug info added to the
compiler generated remat statement’s like loading global constant
/value ,which doesn’t have “.loc” info from the source.
Please share your valuable thoughts on this issue’s.
Assembly and object files are added in mail.
Thanks in Advance,
Jaydeep.
[-- Attachment #2: gdb.s --]
[-- Type: text/plain, Size: 12340 bytes --]
.text
.file "gdb.c"
.file 1 "/home/bft/Jaydeep/llvm_all/check/llvm-project/install/bin" "gdb.c"
.globl main // -- Begin function main
.p2align 2
.type main,@function
main: // @main
.Lfunc_begin0:
.loc 1 3 0 // gdb.c:3:0
.cfi_sections .debug_frame
.cfi_startproc
// %bb.0:
sub sp, sp, #48 // =48
stp x29, x30, [sp, #32] // 16-byte Folded Spill
add x29, sp, #32 // =32
.cfi_def_cfa w29, 16
.cfi_offset w30, -8
.cfi_offset w29, -16
.Ltmp0:
.loc 1 0 0 prologue_end // gdb.c:0:0
adrp x8, garr
adrp x9, garr
add x9, x9, :lo12:garr
stur wzr, [x29, #-4]
.loc 1 5 13 // gdb.c:5:13
ldr w8, [x8, :lo12:garr]
mov w10, #0
str x9, [sp, #16] // 8-byte Folded Spill
str w10, [sp, #12] // 4-byte Folded Spill
.loc 1 5 21 is_stmt 0 // gdb.c:5:21
cbz w8, .LBB0_2
// %bb.1:
.loc 1 0 21 // gdb.c:0:21
ldr x8, [sp, #16] // 8-byte Folded Reload
.loc 1 5 24 // gdb.c:5:24
ldr w9, [x8, #4]
.loc 1 5 21 // gdb.c:5:21
cmp w9, #0 // =0
cset w9, ne
str w9, [sp, #12] // 4-byte Folded Spill
.Ltmp1:
.LBB0_2:
.loc 1 0 21 // gdb.c:0:21
ldr w8, [sp, #12] // 4-byte Folded Reload
.loc 1 5 12 // gdb.c:5:12
tbnz w8, #0, .LBB0_4
// %bb.3:
.loc 1 0 12 // gdb.c:0:12
mov w8, #1
.Ltmp2:
adrp x9, garr
.Ltmp3:
.loc 1 6 24 is_stmt 1 // gdb.c:6:24
str w8, [x9, :lo12:garr]
ldr x9, [sp, #16] // 8-byte Folded Reload
.loc 1 7 24 // gdb.c:7:24
str w8, [x9, #4]
.loc 1 8 9 // gdb.c:8:9
b .LBB0_5
.Ltmp4:
.LBB0_4:
.loc 1 0 9 is_stmt 0 // gdb.c:0:9
mov w8, #2
adrp x9, garr
.Ltmp5:
.loc 1 10 25 is_stmt 1 // gdb.c:10:25
str w8, [x9, :lo12:garr]
ldr x9, [sp, #16] // 8-byte Folded Reload
.loc 1 11 25 // gdb.c:11:25
str w8, [x9, #4]
.Ltmp6:
.LBB0_5:
.loc 1 0 0 is_stmt 0 // gdb.c:0:0
adrp x8, garr
.Ltmp7:
.loc 1 13 27 is_stmt 1 // gdb.c:13:27
ldr w1, [x8, :lo12:garr]
ldr x8, [sp, #16] // 8-byte Folded Reload
.loc 1 13 36 is_stmt 0 // gdb.c:13:36
ldr w2, [x8, #4]
.loc 1 0 0 // gdb.c:0:0
adrp x0, .L.str
add x0, x0, :lo12:.L.str
.loc 1 13 10 // gdb.c:13:10
bl printf
mov w8, wzr
.loc 1 14 10 is_stmt 1 // gdb.c:14:10
mov w0, w8
ldp x29, x30, [sp, #32] // 16-byte Folded Reload
add sp, sp, #48 // =48
ret
.Ltmp8:
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
// -- End function
.type garr,@object // @garr
.bss
.globl garr
.p2align 2
garr:
.zero 8
.size garr, 8
.type .L.str,@object // @.str
.section .rodata.str1.1,"aMS",@progbits,1
.L.str:
.asciz "%d %d\n"
.size .L.str, 7
.section .debug_abbrev,"",@progbits
.byte 1 // Abbreviation Code
.byte 17 // DW_TAG_compile_unit
.byte 1 // DW_CHILDREN_yes
.byte 37 // DW_AT_producer
.byte 14 // DW_FORM_strp
.byte 19 // DW_AT_language
.byte 5 // DW_FORM_data2
.byte 3 // DW_AT_name
.byte 14 // DW_FORM_strp
.byte 16 // DW_AT_stmt_list
.byte 23 // DW_FORM_sec_offset
.byte 27 // DW_AT_comp_dir
.byte 14 // DW_FORM_strp
.byte 17 // DW_AT_low_pc
.byte 1 // DW_FORM_addr
.byte 18 // DW_AT_high_pc
.byte 6 // DW_FORM_data4
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 2 // Abbreviation Code
.byte 52 // DW_TAG_variable
.byte 0 // DW_CHILDREN_no
.byte 3 // DW_AT_name
.byte 14 // DW_FORM_strp
.byte 73 // DW_AT_type
.byte 19 // DW_FORM_ref4
.byte 63 // DW_AT_external
.byte 25 // DW_FORM_flag_present
.byte 58 // DW_AT_decl_file
.byte 11 // DW_FORM_data1
.byte 59 // DW_AT_decl_line
.byte 11 // DW_FORM_data1
.byte 2 // DW_AT_location
.byte 24 // DW_FORM_exprloc
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 3 // Abbreviation Code
.byte 1 // DW_TAG_array_type
.byte 1 // DW_CHILDREN_yes
.byte 73 // DW_AT_type
.byte 19 // DW_FORM_ref4
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 4 // Abbreviation Code
.byte 33 // DW_TAG_subrange_type
.byte 0 // DW_CHILDREN_no
.byte 73 // DW_AT_type
.byte 19 // DW_FORM_ref4
.byte 55 // DW_AT_count
.byte 11 // DW_FORM_data1
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 5 // Abbreviation Code
.byte 36 // DW_TAG_base_type
.byte 0 // DW_CHILDREN_no
.byte 3 // DW_AT_name
.byte 14 // DW_FORM_strp
.byte 62 // DW_AT_encoding
.byte 11 // DW_FORM_data1
.byte 11 // DW_AT_byte_size
.byte 11 // DW_FORM_data1
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 6 // Abbreviation Code
.byte 36 // DW_TAG_base_type
.byte 0 // DW_CHILDREN_no
.byte 3 // DW_AT_name
.byte 14 // DW_FORM_strp
.byte 11 // DW_AT_byte_size
.byte 11 // DW_FORM_data1
.byte 62 // DW_AT_encoding
.byte 11 // DW_FORM_data1
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 7 // Abbreviation Code
.byte 46 // DW_TAG_subprogram
.byte 0 // DW_CHILDREN_no
.byte 17 // DW_AT_low_pc
.byte 1 // DW_FORM_addr
.byte 18 // DW_AT_high_pc
.byte 6 // DW_FORM_data4
.byte 64 // DW_AT_frame_base
.byte 24 // DW_FORM_exprloc
.byte 3 // DW_AT_name
.byte 14 // DW_FORM_strp
.byte 58 // DW_AT_decl_file
.byte 11 // DW_FORM_data1
.byte 59 // DW_AT_decl_line
.byte 11 // DW_FORM_data1
.byte 73 // DW_AT_type
.byte 19 // DW_FORM_ref4
.byte 63 // DW_AT_external
.byte 25 // DW_FORM_flag_present
.byte 0 // EOM(1)
.byte 0 // EOM(2)
.byte 0 // EOM(3)
.section .debug_info,"",@progbits
.Lcu_begin0:
.word .Ldebug_info_end0-.Ldebug_info_start0 // Length of Unit
.Ldebug_info_start0:
.hword 4 // DWARF version number
.word .debug_abbrev // Offset Into Abbrev. Section
.byte 8 // Address Size (in bytes)
.byte 1 // Abbrev [1] 0xb:0x68 DW_TAG_compile_unit
.word .Linfo_string0 // DW_AT_producer
.hword 12 // DW_AT_language
.word .Linfo_string1 // DW_AT_name
.word .Lline_table_start0 // DW_AT_stmt_list
.word .Linfo_string2 // DW_AT_comp_dir
.xword .Lfunc_begin0 // DW_AT_low_pc
.word .Lfunc_end0-.Lfunc_begin0 // DW_AT_high_pc
.byte 2 // Abbrev [2] 0x2a:0x15 DW_TAG_variable
.word .Linfo_string3 // DW_AT_name
.word 63 // DW_AT_type
// DW_AT_external
.byte 1 // DW_AT_decl_file
.byte 2 // DW_AT_decl_line
.byte 9 // DW_AT_location
.byte 3
.xword garr
.byte 3 // Abbrev [3] 0x3f:0xc DW_TAG_array_type
.word 75 // DW_AT_type
.byte 4 // Abbrev [4] 0x44:0x6 DW_TAG_subrange_type
.word 82 // DW_AT_type
.byte 2 // DW_AT_count
.byte 0 // End Of Children Mark
.byte 5 // Abbrev [5] 0x4b:0x7 DW_TAG_base_type
.word .Linfo_string4 // DW_AT_name
.byte 5 // DW_AT_encoding
.byte 4 // DW_AT_byte_size
.byte 6 // Abbrev [6] 0x52:0x7 DW_TAG_base_type
.word .Linfo_string5 // DW_AT_name
.byte 8 // DW_AT_byte_size
.byte 7 // DW_AT_encoding
.byte 7 // Abbrev [7] 0x59:0x19 DW_TAG_subprogram
.xword .Lfunc_begin0 // DW_AT_low_pc
.word .Lfunc_end0-.Lfunc_begin0 // DW_AT_high_pc
.byte 1 // DW_AT_frame_base
.byte 109
.word .Linfo_string6 // DW_AT_name
.byte 1 // DW_AT_decl_file
.byte 3 // DW_AT_decl_line
.word 75 // DW_AT_type
// DW_AT_external
.byte 0 // End Of Children Mark
.Ldebug_info_end0:
.section .debug_str,"MS",@progbits,1
.Linfo_string0:
.asciz "clang version 12.0.0 (https://github.com/llvm/llvm-project.git 6795f3fe9c4bf78df934de5ae448ab908948318d)" // string offset=0
.Linfo_string1:
.asciz "gdb.c" // string offset=105
.Linfo_string2:
.asciz "/home/bft/Jaydeep/llvm_all/check/llvm-project/install/bin" // string offset=111
.Linfo_string3:
.asciz "garr" // string offset=169
.Linfo_string4:
.asciz "int" // string offset=174
.Linfo_string5:
.asciz "__ARRAY_SIZE_TYPE__" // string offset=178
.Linfo_string6:
.asciz "main" // string offset=198
.ident "clang version 12.0.0 (https://github.com/llvm/llvm-project.git 6795f3fe9c4bf78df934de5ae448ab908948318d)"
.section ".note.GNU-stack","",@progbits
.addrsig
.addrsig_sym printf
.addrsig_sym garr
.section .debug_line,"",@progbits
.Lline_table_start0:
[-- Attachment #3: gdb.c --]
[-- Type: text/x-c-code, Size: 297 bytes --]
/* demo testcase */
int garr[2];
int main() {
if((garr[0] && garr[1])==0){
garr[0]=1;
garr[1]=1;
}
else {
garr[0]=2;
garr[1]=2;
}
printf("%d %d\n",garr[0], garr[1]);
return 0;
}
[-- Attachment #4: gdb.o --]
[-- Type: application/octet-stream, Size: 3488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Line number zero in line table gives incorrect debugging experince with gdb
2020-08-27 15:02 ` [gdb]Line number zero in line table gives incorrect debugging experince with gdb Jaydeep Chauhan
@ 2020-08-28 16:59 ` Tom Tromey
2020-08-28 18:03 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2020-08-28 16:59 UTC (permalink / raw)
To: Jaydeep Chauhan via Gdb
>>>>> "Jaydeep" == Jaydeep Chauhan via Gdb <gdb@sourceware.org> writes:
Jaydeep> We have a situation with GDB(latest trunk) and below testcase
Jaydeep> referred for further discussion :
I tried git master gdb today on the gdb.o you sent, and I see a
different result. I can't run the program in question, but setting a
breakpoint seemed to work:
(gdb) b main
Breakpoint 1 at 0x1c: file gdb.c, line 5.
I somewhat expected this, because some fixes here have landed, in
particular:
commit 876518dd0a0b6fd6f4ad0a0b247db0d6a267db27
Author: Tom de Vries <tdevries@suse.de>
Date: Sat Jul 25 00:23:06 2020 +0200
[gdb/symtab] Ignore zero line table entries
Does your tree include this commit?
If so, then I wonder why I see something different. If not, could you
update to (at least) this revision and then try again? Maybe it's been
fixed.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Line number zero in line table gives incorrect debugging experince with gdb
2020-08-28 16:59 ` Line " Tom Tromey
@ 2020-08-28 18:03 ` Simon Marchi
0 siblings, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2020-08-28 18:03 UTC (permalink / raw)
To: Tom Tromey, Jaydeep Chauhan via Gdb
On 2020-08-28 12:59 p.m., Tom Tromey wrote:
>>>>>> "Jaydeep" == Jaydeep Chauhan via Gdb <gdb@sourceware.org> writes:
>
> Jaydeep> We have a situation with GDB(latest trunk) and below testcase
> Jaydeep> referred for further discussion :
>
> I tried git master gdb today on the gdb.o you sent, and I see a
> different result. I can't run the program in question, but setting a
> breakpoint seemed to work:
>
> (gdb) b main
> Breakpoint 1 at 0x1c: file gdb.c, line 5.
>
> I somewhat expected this, because some fixes here have landed, in
> particular:
>
> commit 876518dd0a0b6fd6f4ad0a0b247db0d6a267db27
> Author: Tom de Vries <tdevries@suse.de>
> Date: Sat Jul 25 00:23:06 2020 +0200
>
> [gdb/symtab] Ignore zero line table entries
>
> Does your tree include this commit?
>
> If so, then I wonder why I see something different. If not, could you
> update to (at least) this revision and then try again? Maybe it's been
> fixed.
>
> Tom
>
Jaydeep,
As I replied in the bug you filed [1], I think this is a duplicate of 26243.
The plan was to commit Tom de Vries' patch (which Tom Tromey mentioned above), which brings back
the previous behavior. Then, once the GDB 10 branch is created, revert that and merge other patches
that handle the situation a bit better, such as:
https://sourceware.org/pipermail/gdb-patches/2020-July/170645.html
https://sourceware.org/pipermail/gdb-patches/2020-July/170751.html
Simon
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=26538
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=26243
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-08-28 18:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAMyYBzxgL3NG++gO_Z2AhZXfSTagd6YBAMd=Ej1TbtitAayX3g@mail.gmail.com>
[not found] ` <CAMyYBzwV9dr5Aue-rrrbtLRc30F==OaVih91kpzF8KpBtaqMNQ@mail.gmail.com>
2020-08-27 15:02 ` [gdb]Line number zero in line table gives incorrect debugging experince with gdb Jaydeep Chauhan
2020-08-28 16:59 ` Line " Tom Tromey
2020-08-28 18:03 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).