public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/109902] New: gcc/g++ emits wrong column number in DWARF
@ 2023-05-18 12:26 simon.farre.cx at gmail dot com
  2023-05-18 19:29 ` [Bug debug/109902] " simon.farre.cx at gmail dot com
  0 siblings, 1 reply; 2+ messages in thread
From: simon.farre.cx at gmail dot com @ 2023-05-18 12:26 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 109902
           Summary: gcc/g++ emits wrong column number in DWARF
           Product: gcc
           Version: 12.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon.farre.cx at gmail dot com
  Target Milestone: ---

Created attachment 55111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55111&action=edit
Contains GCC & clang dwarfdump output as well as simple source code.

The DWARF spec, states in paragraph 2.14 "Declaration Coordinates" (version 5,
https://dwarfstd.org/doc/DWARF5.pdf) that:

"The value of the DW_AT_decl_column attribute represents the source column
number at which the first character of the identifier of the declared object
appears. The value 0 indicates that no column has been specified."

Below is an example of contrived C++ code:

auto b = setfoo().setbar().setbaz();

gcc emits column meta data at these positions (represented by _):

auto b = setfoo_().setbar_().setbaz_();

Whereas for instance clang emits it properly, according to spec:

auto b = _setfoo()._setbar()._setbaz();

So for the following code:

"  const auto res1 = b.set_foo (10).set_bar (20).set_baz (30).finalize ([]
(auto v) { return v * 2; });"

The following line number program is emitted (the line number is 66 and set_foo
begins on column position 23)

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000401150     66     31      1   0             0  is_stmt
0x0000000000401161     66     44      1   0             0  is_stmt
0x000000000040116e     66     57      1   0             0  is_stmt
0x000000000040117b     66     71      1   0             0  is_stmt

0x000000000040126c     66     72      1   0             0  is_stmt
0x0000000000401277     66     97      1   0             0  is_stmt
0x000000000040127c     66    100      1   0             0  is_stmt

Where as clang emits:

0x000000000040114b     66     23      1   0             0  is_stmt
0x000000000040115e     66     36      1   0             0
0x0000000000401171     66     49      1   0             0
0x0000000000401179     66     62      1   0             0

0x0000000000401430     66      0      1   0             0  is_stmt
0x000000000040143b     66     93      1   0             0  is_stmt prologue_end
0x000000000040143e     66     95      1   0             0
0x0000000000401441     66     86      1   0             0

It's also questionable if GCC emits the correct meta data with respect to
statements, but I guess that's a different issue.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug debug/109902] gcc/g++ emits wrong column number in DWARF
  2023-05-18 12:26 [Bug debug/109902] New: gcc/g++ emits wrong column number in DWARF simon.farre.cx at gmail dot com
@ 2023-05-18 19:29 ` simon.farre.cx at gmail dot com
  0 siblings, 0 replies; 2+ messages in thread
From: simon.farre.cx at gmail dot com @ 2023-05-18 19:29 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Simon Farre <simon.farre.cx at gmail dot com> ---
This is slightly off-topic, but still relevant to this discussion. In the
attachment,
we can see this line

"  const auto res3 = b.set_foo (next_v ()).set_bar (next_v ()).set_baz (next_v
()).finalize ([] (auto v) { return v * 3; });"

-- GCC --
Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x00000000004011ee     68     31      1   0             0  is_stmt
0x0000000000401206     68     51      1   0             0  is_stmt
0x0000000000401218     68     71      1   0             0  is_stmt
0x0000000000401227     68     92      1   0             0  is_stmt

0x00000000004012ee     68     93      1   0             0  is_stmt
0x00000000004012f9     68    118      1   0             0  is_stmt
0x0000000000401302     68    121      1   0             0  is_stmt

where as clang outputs:
Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x00000000004011fd     68     32      1   0             0  is_stmt
0x000000000040120b     68     23      1   0             0
0x0000000000401217     68     52      1   0             0
0x0000000000401225     68     43      1   0             0
0x0000000000401231     68     72      1   0             0
0x000000000040123f     68     63      1   0             0
0x0000000000401247     68     83      1   0             0

0x0000000000401450     68      0      1   0             0  is_stmt
0x000000000040145b     68    116      1   0             0  is_stmt prologue_end
0x000000000040145f     68    107      1   0             0
0x0000000000401461     68    107      1   0             0  end_sequence


As we can see, clang outputs information to the actual column meta data for
calls at parameter sites whereas GCC does not. Providing these positions in
source code opens up for "ergonomics-features", particularly in GDB as GDB can
more easily determine sites of interest to step to, set breakpoints at, etc.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-05-18 19:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-18 12:26 [Bug debug/109902] New: gcc/g++ emits wrong column number in DWARF simon.farre.cx at gmail dot com
2023-05-18 19:29 ` [Bug debug/109902] " simon.farre.cx at gmail dot com

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).