https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
Bug ID: 92983
Summary: [8/9/10 Regression] Debug info regression since
PR87428 changes
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, hubicka at gcc dot gnu.org,
jason at gcc dot gnu.org, mark at gcc dot gnu.org,
rguenth at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux
Created attachment 47518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47518&action=edit
nfs3proc.i
On the following testcase distilled from Linux kernel nfs3proc.c, when compiled
on x86_64-linux e.g. with -g -O2 -dA, the nfs3_commit_done function is split by
the fnsplit pass and later inlined into itself, furthermore, the "cold" part
doesn't have the task parameter passed to it.
Before PR87428 (on the trunk r264594, but backported to release branches) we
used to emit DW_TAG_subprogram for the abstract instance and then
DW_TAG_subprogram with DW_AT_abstract_origin pointing to that with
DW_AT_location for the task DW_TAG_formal_parameter and then weirdo
DW_TAG_lexical_block with DW_TAG_formal_parameter for the inlined copy of the
rest of the function. The DW_TAG_formal_parameter for task in that
DW_TAG_lexical_block didn't have any DW_AT_location.
Now, the above mentioned changes make it to some extent more correct by using
DW_TAG_inlined_subroutine instead of DW_TAG_lexical_block, but break tools like
systemtap when e.g. asked to print the task parameter on the first line of the
nfs3_commit_done function, because that will try to put a breakpoint both at
the
start of the nfs3_commit_done function where it will find the argument, and at
the start of the DW_TAG_inlined_subroutine because it says it is another copy
of the function, and task isn't available there.
Ideally, we'd try to undo all the damage done to debug info when inlining
fnsplit body back into itself.
If that can't be done, we should at least tell the debug info consumers that
this is happening, I know Alex posted a partial inlining specific patch for
that
and I've wanted something that would be more specific on the why it is a
partially outlined function, see e.g.
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01941.html
Until that is done, wonder especially for release branches if we couldn't note
this somewhere during fnsplit + inlining it back and represent as
DW_TAG_lexical_block rather than DW_TAG_inlined_subroutine, plus perhaps use
DW_TAG_variable rather than DW_TAG_formal_parameter for the "parameters".
