[Bug macros/29725] New: Dwarf 5 C macros not handled

[Bug macros/29725] New: Dwarf 5 C macros not handled

[drepper.fsp at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29725

            Bug ID: 29725
           Summary: Dwarf 5 C macros not handled
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: macros
          Assignee: unassigned at sourceware dot org
          Reporter: drepper.fsp at gmail dot com
  Target Milestone: ---

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414 for the gcc
maintainer's analysis.  Jakub thinks this is a gdb issue.

Copied from the gcc bug:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Take
this code:

union node {
  struct {
    int a;
  } l;
} x;

#define memory l.a

int main()
{
  return x.memory;
}

When compiled with -gdwarf-4 -g3 and run in gdb, it is possible to use

Breakpoint 1, main () at u.c:11
11        return x.memory;
(gdb) p x.memory
$1 = 0

When instead -gdwarf-5 -g3 is used 'memory' is not known to be a macro and one
gets

Breakpoint 1, main () at u.c:11
11        return x.memory;
(gdb) p x.memory
There is no member named memory.

Shouldn't the Dwarf 5 data be a superset of what Dwarf 4 provides?

This is not new in the trunk/13 version.  12.1 fails as well and likely prior
versions, too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/29725] Dwarf 5 C macros not handled

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=29725

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #1 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Works for me on GDB master.  Likely fixed by this series:

https://inbox.sourceware.org/gdb-patches/20220428033542.1636284-1-simon.marchi@polymtl.ca/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/29725] Dwarf 5 C macros not handled

[drepper.fsp at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29725

--- Comment #2 from Ulrich Drepper <drepper.fsp at gmail dot com> ---
Indeed, seems to work.

But the sequence is just part of the bigger code base.  Something like this is
used in gawk.  It seems the macro parser gets confused for larger code bases. 
The specific macro is used in a similar form in gawk (it's just a larger
structure/union).

This is the procedure to reproduce:

        cd /path/to/gawk/repo
        git pull
        echo debug > .developing
        ./bootstrap.sh && ./configure && make
        gdb ./gawk
        (gdb) break mk_binary
        (gdb) run -f test/divzero2.awk

Get to line 5539 and try to print ip2->memory->flags. I get:

        (gdb) p ip2->memory->flags
        There is no member named memory.

This is what I get even with the trunk gdb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/29725] Dwarf 5 C macros not handled

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=29725

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
Thanks, I think I was able to reproduce.  Your instructions should probably
include CFLAGS="-g3" though?

So, I do this to reach the point in the code that you described:

$ /home/simark/build/binutils-gdb/gdb/gdb
--data-directory=/home/simark/build/binutils-gdb/gdb/data-directory -nx -q
./gawk -ex "b mk_binary" -ex "run -f test/divzero2.awk" -ex "advance 5539"

(gdb) info macro memory
The symbol `memory' has no definition as a C/C++ preprocessor macro
at /home/simark/src/gawk/awkgram.c:-1

This -1 line number is fishy.

Debugging gdb and breaking on macro_lookup_inclusion, and re-running "info
macro memory", I can see that we do this:

    if (filename_cmp (name, source->filename) == 0)
      return source;      

Ref:
https://gitlab.com/gnutools/binutils-gdb/-/blob/ecb58b32cdeb9789f9bc7c2037cb001d9a729f83/gdb/macrotab.c#L511

(top-gdb) p name
$1 = 0x621000136670 "/home/simark/src/gawk/awkgram.y"
(top-gdb) p source->filename
$2 = 0x621000136610 "/home/simark/src/gawk/awkgram.c"

So, GDB is getting confused because of the different source filenames.

Did this really work previously, using DWARF 4 and an older GDB?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/29725] Dwarf 5 C macros not handled

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=29725

--- Comment #4 from Simon Marchi <simark at simark dot ca> ---
I don't think GDB has enough debug info to figure this out.

With a simple case, it works as expected:

$ cat test.c
#define FOO 2
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
Defined at /home/simark/build/binutils-gdb/gdb/test.c:1
#define FOO 2

But then if you add a line control directive, like you have for a .c file
generated from a .y file:
$ cat test.c
#define FOO 2
#line 17 "potato.c"
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
The symbol `FOO' has no definition as a C/C++ preprocessor macro
at /home/simark/build/binutils-gdb/gdb/test.c:-1

Looking at the macro debug info (my annotations after the #s):

$ readelf --debug-dump=macro a.out

 DW_MACRO_import - offset : 0x20 # built-in macros
 DW_MACRO_start_file - lineno: 0 filenum: 2 # test.c
 DW_MACRO_start_file - lineno: 0 filenum: 3 # stdc-predef.h
 DW_MACRO_import - offset : 0x900 # STDC macros
 DW_MACRO_end_file # end of stdc-predef.h
 DW_MACRO_define_strp - lineno : 1 macro : FOO 2
    <--- here
 DW_MACRO_end_file # end of test.c

The line table tells GDB that the current PC is in potato.c, line 17:

CU: ./test.c:
File name                            Line number    Starting address    View   
Stmt
potato.c                                      17              0x1119           
   x
potato.c                                      17              0x111d           
   x
potato.c                                      17              0x1122           
   x
potato.c                                       -              0x1124

But GDB has no way to figure out where this is in the macro inclusion tree, as
potato.c is never represented in there.  Ideally, GDB would figure out that we
are where I maked `here`, above.

Looking at the DWARF opcodes for macro, I don't really see a way to describe
the #line stuff.  There's only DW_MACRO_start_file, which represents the
inclusion of a complete file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.