Bug 2183525

Summary: Cannot set breakpoint unless add -gno-statement-frontiers to compiler arguments
Product: Red Hat Enterprise Linux 8 Reporter: Paulo Andrade <pandrade>
Component: gccAssignee: Marek Polacek <mpolacek>
gcc sub component: system-version QA Contact: qe-baseos-tools-bugs
Status: CLOSED UPSTREAM Docs Contact:
Severity: medium    
Priority: unspecified CC: ahajkova, fweimer, jakub, ohudlick, sipoyare
Version: 8.7   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-04 16:18:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paulo Andrade 2023-03-31 13:56:29 UTC
Example reproducer:

$ mkdir test
$ cd test
$ ../debuginfo-problem.sh

To test the workaround, edit debuginfo.sh and uncomment the line:

#workaround="-gno-statement-frontiers"

The problem also goes away if compiling with -O0.

Comment 1 Paulo Andrade 2023-03-31 13:57:01 UTC
Created attachment 1954891 [details]
debuginfo-problem.sh

Comment 2 Marek Polacek 2023-04-03 21:38:18 UTC
Reduced:

$ cat main.cc
#include "test.h"

void invokeInline (Message & msg, int param)
{
  someInlineFunction (msg, param);
}

int main ()
{
  Message msg;
  invokeInline (msg, 42);
}

$ cat test.h 
struct Message {
  int member{35};
};

template<typename T>
void someInlineFunction (T & msg, int value)
{
   msg.member += value;
}

$ g++ -Og -g main.cc
$ gdb --nh --batch -ex 'break test.h:9' -ex run ./a.out
No line 9 in file "test.h".
[...]
$ g++ -Og -g main.cc -gno-statement-frontiers
$ gdb --nh --batch -ex 'break test.h:9' -ex run ./a.out
Breakpoint 1 at 0x40113b: file /home/mpolacek/x/trunk/gcc/r/test.h, line 9.
[...]

Started with r255569.  I don't know anything about statement frontier notes but saying "No line 9 in file "test.h"" seems confusing at least.
Happens with upstream trunk as well, so I suppose I'll have to take this upstream.

Comment 3 Marek Polacek 2023-04-03 21:42:00 UTC
$ diff -up 1.s 2.s
--- 1.s	2023-04-03 17:41:07.446108328 -0400
+++ 2.s	2023-04-03 17:41:12.891102304 -0400
@@ -11,7 +11,7 @@ _Z18someInlineFunctionI7MessageEvRT_i:
 	.file 1 "test.h"
 	.loc 1 6 6 view -0
 	.cfi_startproc
-	.loc 1 8 15 is_stmt 0 view .LVU1
+	.loc 1 8 15 view .LVU1
 	addl	%esi, (%rdi)
 	.loc 1 9 1 view .LVU2
 	ret
@@ -25,16 +25,15 @@ _Z12invokeInlineR7Messagei:
 .LVL1:
 .LFB1:
 	.file 2 "main.cc"
-	.loc 2 4 1 is_stmt 1 view -0
+	.loc 2 4 1 view -0
 	.cfi_startproc
 	.loc 2 4 1 is_stmt 0 view .LVU4
 	subq	$8, %rsp
 	.cfi_def_cfa_offset 16
-	.loc 2 5 3 is_stmt 1 view .LVU5
-	.loc 2 5 22 is_stmt 0 view .LVU6
+	.loc 2 5 22 is_stmt 1 view .LVU5
 	call	_Z18someInlineFunctionI7MessageEvRT_i
 .LVL2:
-	.loc 2 6 1 view .LVU7
+	.loc 2 6 1 view .LVU6
 	addq	$8, %rsp
 	.cfi_def_cfa_offset 8
 	ret
@@ -45,20 +44,18 @@ _Z12invokeInlineR7Messagei:
 	.type	main, @function
 main:
 .LFB2:
-	.loc 2 9 1 is_stmt 1 view -0
+	.loc 2 9 1 view -0
 	.cfi_startproc
 	subq	$24, %rsp
 	.cfi_def_cfa_offset 32
-	.loc 2 10 3 view .LVU9
-	.loc 2 10 11 is_stmt 0 view .LVU10
+	.loc 2 10 11 view .LVU8
 	movl	$35, 12(%rsp)
-	.loc 2 11 3 is_stmt 1 view .LVU11
-	.loc 2 11 16 is_stmt 0 view .LVU12
+	.loc 2 11 16 view .LVU9
 	movl	$42, %esi
 	leaq	12(%rsp), %rdi
 	call	_Z12invokeInlineR7Messagei
 .LVL3:
-	.loc 2 12 1 view .LVU13
+	.loc 2 12 1 view .LVU10
 	movl	$0, %eax
 	addq	$24, %rsp
 	.cfi_def_cfa_offset 8
@@ -499,8 +496,8 @@ main:
 .Ldebug_loc0:
 .LVUS0:
 	.uleb128 0
-	.uleb128 .LVU7
-	.uleb128 .LVU7
+	.uleb128 .LVU6
+	.uleb128 .LVU6
 	.uleb128 0
 .LLST0:
 	.byte	0x6
@@ -521,8 +518,8 @@ main:
 	.byte	0
 .LVUS1:
 	.uleb128 0
-	.uleb128 .LVU7
-	.uleb128 .LVU7
+	.uleb128 .LVU6
+	.uleb128 .LVU6
 	.uleb128 0
 .LLST1:
 	.byte	0x6
@@ -578,12 +575,12 @@ main:
 	.section	.debug_str,"MS",@progbits,1
 .LASF5:
 	.string	"param"
+.LASF6:
+	.string	"GNU C++17 13.0.1 20230403 (experimental) [master revision bf0a3968f5c:7cead0fcb69:f671b3d79fe1ff729e1a3478e38c4839e439d90b] -mtune=generic -march=x86-64 -g -gno-statement-frontiers -Og"
 .LASF8:
 	.string	"member"
 .LASF10:
 	.string	"invokeInline"
-.LASF6:
-	.string	"GNU C++17 13.0.1 20230403 (experimental) [master revision bf0a3968f5c:7cead0fcb69:f671b3d79fe1ff729e1a3478e38c4839e439d90b] -mtune=generic -march=x86-64 -g -Og"
 .LASF2:
 	.string	"value"
 .LASF11:

Comment 4 Marek Polacek 2023-04-04 16:18:06 UTC
I've opened an upstream PR: <https://gcc.gnu.org/PR109411> but unfortunately this area
isn't developed very actively.  So we'll have to see if the upstream resolves this in
some way.  Therefore, I'm closing this BZ, since I don't expect this to be fixed any
time soon.  -gno-statement-frontiers is a workaround.