• Basile B (71/71) Sep 17 2021 I've just reached something strange when debugging code, here's a
• Johan (6/26) Sep 17 2021 Yeah I've known about this issue for a long time. Haven't found

Basile B <b2.temp gmx.com> writes:

I've just reached something strange when debugging code, here's a 
repro:

1. create bad_debug_lines.d with the following content

```d
module bad_debug_lines;

extern(C) int rand();

int call() {
     return 1 + rand() % 8; // defeat opts...
}

void main() {
     if (call() &&
         call() &&
         call() &&
         call())
     {}
}
```

2. in a console

```bash
[xxxx pc temp]$ gdb ./bad_debug_lines
GNU gdb (GDB) Fedora 10.2-1.fc33
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bad_debug_lines...
(gdb) b bad_debug_lines.d:10
Breakpoint 1 at 0x402758: file bad_debug_lines.d, line 10.
(gdb) b bad_debug_lines.d:11
Breakpoint 2 at 0x4027ba: file bad_debug_lines.d, line 15.
(gdb) b bad_debug_lines.d:12
Note: breakpoint 2 also set at pc 0x4027ba.
Breakpoint 3 at 0x4027ba: file bad_debug_lines.d, line 15.
(gdb) b bad_debug_lines.d:13
Note: breakpoints 2 and 3 also set at pc 0x4027ba.
Breakpoint 4 at 0x4027ba: file bad_debug_lines.d, line 15.
(gdb) run
Starting program: /home/basile/Bureau/temp/bad_debug_lines
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, D main () at bad_debug_lines.d:10
10          if (call() &&
Missing separate debuginfos, use: dnf debuginfo-install 
glibc-2.32-10.fc33.x86_64 libgcc-10.3.1-1.fc33.x86_64
(gdb) c
Continuing.

Breakpoint 2, D main () at bad_debug_lines.d:15
15      }
(gdb) q
A debugging session is active.

         Inferior 1 [process 15789] will be killed.

Quit anyway? (y or n) y
```

so it's not possible to debug conditions in && (same for OrOrExp 
btw), even when the operands stand on their own line.

At least two breakpoints should work. That seems to be the case 
but the
second indicates line 15.

The problem is somewhat confirmed by the IR view:
https://godbolt.org/z/bsfaPvPbE, as you can see the coloured 
block for the ifcondition is only 1 line long.

Johan <j j.nl> writes:

On Friday, 17 September 2021 at 13:42:48 UTC, Basile B wrote:
 I've just reached something strange when debugging code, here's 
 a repro:

 1. create bad_debug_lines.d with the following content

 ```d
 module bad_debug_lines;

 extern(C) int rand();

 int call() {
     return 1 + rand() % 8; // defeat opts...
 }

 void main() {
     if (call() &&
         call() &&
         call() &&
         call())
     {}
 }
 ```

[...]
 The problem is somewhat confirmed by the IR view:
 https://godbolt.org/z/bsfaPvPbE, as you can see the coloured 
 block for the ifcondition is only 1 line long.

Yeah I've known about this issue for a long time. Haven't found 
the time to fix it. Your post does add a little motivation for 
fixing it :)

-Johan