[Bug gdb/26538] New: Line number zero in line table gives incorrect debugging experince with gdb

[Bug gdb/26538] New: Line number zero in line table gives incorrect debugging experince with gdb

[jaydeepchauhan1494 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26538

            Bug ID: 26538
           Summary: Line number zero in line table gives incorrect
                    debugging experince with gdb
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: jaydeepchauhan1494 at gmail dot com
  Target Milestone: ---

Created attachment 12798
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12798&action=edit
Attached Assembly file.

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 issue’s 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 test.c, line 0.

It should be, something like 

(gdb) b main
Breakpoint 1 at 0x800005ec: file test.c, line 3.


2) 
Breakpoint 1, main () at test.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.

Also attached assembly file in bug for reference.

Please share your valuable thoughts on this issue’s.

Thanks in Advance,
Jaydeep.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26538] Line number zero in line table gives incorrect debugging experince with gdb

[jaydeepchauhan1494 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26538

Jaydeep Chauhan <jaydeepchauhan1494 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com,
                   |                            |nickc at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26538] Line number zero in line table gives incorrect debugging experince with gdb

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=26538

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Can you please check if this is a duplicate of

https://sourceware.org/bugzilla/show_bug.cgi?id=26243

?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26538] Line number zero in line table gives incorrect debugging experince with gdb

[jaydeepchauhan1494 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26538

Jaydeep Chauhan <jaydeepchauhan1494 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jaydeep Chauhan <jaydeepchauhan1494 at gmail dot com> ---
Yes @Simon Marchi, it is a duplicate issue of 26243.

*** This bug has been marked as a duplicate of bug 26243 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.