[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-04-01

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
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

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
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 <input>: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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
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
17        int i = foo (0);
(gdb) s
foo (x=0) at x.c:3
3         if (x != 0)
(gdb) s
foo (x=<optimized out>) at x.c:5
5         __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0  foo (x=<optimized out>) at x.c:5
0
0
0
0
0
0
0
0x0000000000400522 in main () at x.c:17
17        int i = foo (0);
Value returned is $1 = 0

arranging the head to be inlined into main

Temporary breakpoint 1, main () at x.c:17
17        int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17        int i = foo (0);
(gdb) s
foo (x=<optimized out>) at x.c:5
5         __builtin_printf ("%d\n", x);
(gdb) fin
Run till exit from #0  foo (x=<optimized out>) at x.c:5
0
0
0
0
0
0
0
__libc_start_main (main=0x400430 <main>, argc=1, argv=0x7fffffffde98, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde88) 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
17        int 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
0x0000000000400522 in main () at x.c:17
17        int i = foo (0);

now with the proposed patch:

Temporary breakpoint 1, main () at x.c:16
16      {
(gdb) s
17        int 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
0x0000000000400542 in foo.part () at x.c:18
18        return i;
Value returned is $1 = 2
(gdb) fin
Run till exit from #0  0x0000000000400542 in foo.part () at x.c:18
0
0
0
0
0
0
0x0000000000400522 in main () at x.c:17
17        int i = foo (0);

and

Temporary breakpoint 1, main () at x.c:17
17        int i = foo (0);
(gdb) s
foo (x=0) at x.c:17
17        int i = foo (0);
(gdb) 
0x0000000000400520 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
0x0000000000400532 in foo.part ()
Value returned is $1 = 2
(gdb) fin
Run till exit from #0  0x0000000000400532 in foo.part ()
0
0
0
0
0
0
__libc_start_main (main=0x400430 <main>, argc=1, argv=0x7fffffffde98, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde88) 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
17        int 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
0x0000000000400552 in foo (x=<optimized out>) at x.c:1
1       int foo (int x)
Value returned is $1 = 2
(gdb) fin
Run till exit from #0  0x0000000000400552 in foo (x=<optimized out>) at x.c:1
0
0
0
0
0
0
0x0000000000400522 in main () at x.c:17
17        int 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 optimal representation
for the gdb side.  I suppose for the split function case re-inlining
the tail should be transparent but that's not how the block tree side
looks like.  For the case where the head is inlined there's no way
but to have the entry to the head visible as inlined subroutine - and
since the actual call to the tail creates a new frame I don't see how
a consumer can not make it visible (in the patched case above you see
gdb simply presents the symbol here and we've elided _all_ debuginfo
which clearly isn't what we want).  So for the outline case we maybe
need a DWARF extension telling the consumer (would maybe also help
OMP outlined functions).

So no, at this point I'm not going to push the simple proposed patch,
it seems to need care on the dwarf2out side at least (and eventually
some guality testcase with all inlining variants of a call to a split
function).

[Bug debug/92983] [8/9/10/11 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug debug/92983] [9/10/11/12 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug debug/92983] [9/10/11/12 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug debug/92983] [10/11/12/13 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug debug/92983] [10/11/12/13 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug debug/92983] [11/12/13/14 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.