[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Richard Biener ---
So I did some more experiments. With
int foo (int x)
{
if (x != 0)
return 1;
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
__builtin_printf ("%d\n", x);
return 0;
}
int main()
{
int i = foo (0);
return i;
}
IPA split splits foo. Arranging things (unpatched) to not inline anything
after splitting does
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:3
3 if (x != 0)
(gdb) s
foo (x=) at x.c:5
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=) at x.c:5
0
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
Value returned is $1 = 0
arranging the head to be inlined into main
Temporary breakpoint 1, main () at x.c:17
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17int i = foo (0);
(gdb) s
foo (x=) at x.c:5
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=) at x.c:5
0
0
0
0
0
0
0
__libc_start_main (main=0x400430 , argc=1, argv=0x7fffde98,
init=, fini=, rtld_fini=,
stack_end=0x7fffde88) at libc-start.c:323
323 libc-start.c: No such file or directory.
Value returned is $1 = 0
arranging the tail to be re-inlined into the head:
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
5 __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0 foo (x=0) at x.c:5
0
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
now with the proposed patch:
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
__printf (format=0x400644 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=0x400644 "%d\n") at printf.c:28
0
0x00400542 in foo.part () at x.c:18
18return i;
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400542 in foo.part () at x.c:18
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
and
Temporary breakpoint 1, main () at x.c:17
17int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17int i = foo (0);
(gdb)
0x00400520 in foo.part ()
(gdb)
Single stepping until exit from function foo.part.0,
which has no line number information.
__printf (format=0x400634 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=0x400634 "%d\n") at printf.c:28
0
0x00400532 in foo.part ()
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400532 in foo.part ()
0
0
0
0
0
0
__libc_start_main (main=0x400430 , argc=1, argv=0x7fffde98,
init=, fini=, rtld_fini=,
stack_end=0x7fffde88) at libc-start.c:323
323 libc-start.c: No such file or directory.
and finally
Temporary breakpoint 1, main () at x.c:16
16 {
(gdb) s
17int i = foo (0);
(gdb)
foo (x=0) at x.c:3
3 if (x != 0)
(gdb)
1 int foo (int x)
(gdb)
__printf (format=format@entry=0x400634 "%d\n") at printf.c:28
28 printf.c: No such file or directory.
(gdb) fin
Run till exit from #0 __printf (format=format@entry=0x400634 "%d\n")
at printf.c:28
0
0x00400552 in foo (x=) at x.c:1
1 int foo (int x)
Value returned is $1 = 2
(gdb) fin
Run till exit from #0 0x00400552 in foo (x=) at x.c:1
0
0
0
0
0
0
0x00400522 in main () at x.c:17
17int i = foo (0);
Value returned is $2 = 0
to me that clearly isn't an improvement :/
I guess gdb doesn't like the DW_TAG_inlined_subroutine for DECL_INGORED_P
entities - in this case we end up with
<2><18e>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
<18f> DW_AT_entry_pc: 0x400540
<197> DW_AT_GNU_entry_view: 1
<198> DW_AT_ranges : 0x40
<19c> DW_AT_call_file : 1
<19d> DW_AT_call_line : 1
<19e> DW_AT_call_column : 5
<19f> DW_AT_sibling : <0x1b1>
but there's no abstract origin here. Of course the whole point of the
patch was to avoid the "inline" as that would appear as a breakpoint
location.
I suppose in dwarf2out we should elide the use of DW_TAG_inlined_subroutine
for DECL_IGNORED (or even DECL_ARTIFICIAL?) functions and instead just
emit a lexical block (w/o abstract origin)?
That said, as usual it's difficult to say what is an appropriate DWARF
representation for the issue at hand and what's the
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
--- Comment #7 from Jeffrey A. Law ---
So I first took a clean RHEL 8.1 system with kernel-4.18.0-147 and verified
that this simple stap script would fail:
stap -p4 -e 'probe module("nfsv3").function("nfs3_commit_done") {
println($task) }'
Which barfs with something like this output:
semantic error: failed to retrieve location attribute for 'task' [man
error::dwarf]: identifier '$task' at :1:62
dieoffset: 0x8068a from
/usr/lib/debug/lib/modules/4.18.0-105.el8.x86_64/kernel/fs/nfs/nfsv3.ko.debug
function: nfs3_commit_done at fs/nfs/nfs3proc.c:847:2 inlined by
nfs3_commit_done at fs/nfs/nfs3proc.c:840:12
source: probe module("nfsv3").function("nfs3_commit_done") {
println($task) }
I then rebuilt/reinstalled GCC with the patch in c#3, then rebuilt the kernel
with the updated GCC.
The simple stap script above is handled without error (generates a suitable .ko
file).
So it definitely helps. Richi, do you want to move forward with this?
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- I'll see if if the proposed solution makes a difference for the case that was originally filed against stap.
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-04-01 --- Comment #5 from Richard Biener --- Not sure if really wrong-debug, waiting for feedback on the proposed solution.
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.4 |8.5 --- Comment #4 from Jakub Jelinek --- GCC 8.4.0 has been released, adjusting target milestone.
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
--- Comment #3 from Richard Biener ---
Isn't the issue that we say the split function parts are actually the original
function? If the tail were artificial there shouldn't be two breakpoints
but still a correct inlined subroutine (of an artificial function)? Similar
issues exist for clones where the signature doesn't really match reality
and which we should represent as artificial functions with an inlined
(with constant / optimized away params) copy of the original function.
That is, tree_function_versioning sets DECL_ABSTRACT_ORIGIN
#0 tree_function_versioning (
old_decl=,
new_decl=,
tree_map=0x0, param_adjustments=0x346e090, update_clones=false,
blocks_to_copy=0x340a748, new_entry=)
at /tmp/trunk2/gcc/tree-inline.c:6130
#1 0x00b48a03 in cgraph_node::create_version_clone_with_body (
this=,
redirect_callers=..., tree_map=0x0, param_adjustments=0x346e090,
bbs_to_copy=0x340a748, new_entry_block=,
suffix=0x2ba39b5 "part", target_attributes=)
at /tmp/trunk2/gcc/cgraphclones.c:1037
#2 0x021540a7 in split_function (
return_bb=,
split_point=0x335da40 , add_tsan_func_exit=false)
now, when changing DECL_ABSTRACT_ORIGIN to NULL we later ICE when cloning
this node for ISRA because tree_function_versioning does
6122 /* Output the inlining info for this abstract function, since it has
been
6123 inlined. If we don't do this now, we can lose the information
about the
6124 variables in the function when the blocks get blown away as soon
as we
6125 remove the cgraph node. */
6126 (*debug_hooks->outlining_inline_function) (old_decl);
but the old_decl is DECL_ARTIFICIAL and it didn't have early dwarf generated
(but what for anyways?). I guess we want the actual outlined BLOCKs to
have an abstract origin to the original functions copy? But clearly not
the decl itself. I'm hesitant to set DECL_IGNORED_P on it but that avoids
the ICEing. The debug info then looks sane though - can you verify?
Index: gcc/ipa-split.c
===
--- gcc/ipa-split.c (revision 279944)
+++ gcc/ipa-split.c (working copy)
@@ -1358,6 +1358,9 @@ split_function (basic_block return_bb, c
split_point->split_bbs, split_point->entry_bb, "part");
delete adjustments;
node->split_part = true;
+ /* Do not pretend the tail is a representation of the actual function. */
+ DECL_ABSTRACT_ORIGIN (node->decl) = NULL_TREE;
+ DECL_IGNORED_P (node->decl) = 1;
if (cur_node->same_comdat_group)
{
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 --- Comment #2 from Jakub Jelinek --- To correct myself, task DW_TAG_formal_parameter in the DW_TAG_inlined_subroutine does have actually DW_AT_location, but at least in the 8.3 version starts with DW_OP_GNU_entry_value. That said, it is still very wrong to assume the partial inlined function (especially when inlined back into itself) is the entry point of the function. And the rest is just kernel screw-up of KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 --- Comment #1 from Jakub Jelinek --- The assembler diff between r264593 and r264594, when ignoring offsets etc., is: - .uleb128 0x27 # (DIE (0x4b6) DW_TAG_lexical_block) + .uleb128 0x27 # (DIE (0x4b6) DW_TAG_inlined_subroutine) .long 0x1ee # DW_AT_abstract_origin .quad .LBB53 # DW_AT_low_pc .quad .LBE53-.LBB53 # DW_AT_high_pc - .long 0x4ef # DW_AT_sibling - .uleb128 0x1e # (DIE (0x4cf) DW_TAG_formal_parameter) + .byte 0x1 # DW_AT_call_file (nfs3proc.i) + .byte 0x4b# DW_AT_call_line + .byte 0xc # DW_AT_call_column + .long 0x4f2 # DW_AT_sibling + .uleb128 0x1e # (DIE (0x4d2) DW_TAG_formal_parameter) .long 0x1ff # DW_AT_abstract_origin .long .LLST8 # DW_AT_location
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.4
