public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "simon.marchi at polymtl dot ca" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/107414] dwarf 5 C macro support
Date: Thu, 27 Oct 2022 01:27:25 +0000	[thread overview]
Message-ID: <bug-107414-4-4F9atUK0Kd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-107414-4@http.gcc.gnu.org/bugzilla/>

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

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

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

--- Comment #5 from Simon Marchi <simon.marchi at polymtl dot ca> ---
The original reproducer Ulrich gave indeed seems like what was fixed in GDB
master recently.  Macros in the main source file didn't work with DWARF 5. 
That works fine now.

But he pointed me to a real-life case in gawk, where it didn't work:

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

That seems to highlight a new problem, that is the use of macros combined with
#line directives.  I don't think that the debug info is sufficient for GDB to
figure this out.

For convenience, here's a copy of what I posted on the GDB bug.

---

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.

      parent reply	other threads:[~2022-10-27  1:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26  9:25 [Bug debug/107414] New: " drepper.fsp+rhbz at gmail dot com
2022-10-26  9:34 ` [Bug debug/107414] " jakub at gcc dot gnu.org
2022-10-26 10:00 ` drepper.fsp+rhbz at gmail dot com
2022-10-26 11:37 ` pinskia at gcc dot gnu.org
2022-10-26 22:05 ` drepper.fsp+rhbz at gmail dot com
2022-10-27  1:27 ` simon.marchi at polymtl dot ca [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-107414-4-4F9atUK0Kd@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).