public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info
@ 2015-07-01 17:39 uweigand at gcc dot gnu.org
2015-07-01 17:48 ` [Bug debug/66728] " uweigand at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: uweigand at gcc dot gnu.org @ 2015-07-01 17:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
Bug ID: 66728
Summary: CONST_WIDE_INT causes corrupted DWARF debug info
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
Target Milestone: ---
Compiling the following test case:
__uint128_t test(void)
{
static const __uint128_t two127 = ((__uint128_t) 1) << 127;
return two127;
}
on x86_64-linux (or ppc64le-linux) with -O -S -g -dA results in:
.uleb128 0x2 # (DIE (0x2d) DW_TAG_subprogram)
# DW_AT_external
.long .LASF3 # DW_AT_name: "test"
[snip]
.uleb128 0x3 # (DIE (0x4e) DW_TAG_variable)
.long .LASF4 # DW_AT_name: "two127"
.byte 0x1 # DW_AT_decl_file (xxx.i)
.byte 0x4 # DW_AT_decl_line
.long 0x61 # DW_AT_type
.byte 0 # end of children of DIE 0x2d
But abbreviation 3 (used for the 0x4e DIE) reads:
.uleb128 0x3 # (abbrev code)
.uleb128 0x34 # (TAG: DW_TAG_variable)
.byte 0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x3a # (DW_AT_decl_file)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3b # (DW_AT_decl_line)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
.uleb128 0x1c # (DW_AT_const_value)
.uleb128 0xa # (DW_FORM_block1)
.byte 0
.byte 0
So the variable DIE should have an DW_AT_const_value attribute encoded as
DW_FORM_block1. This makes sense, since the variable was optimized away due to
being constant, and the size of the constant is 16 bytes.
However, the code in .debug_info to construct the DIE does not emit any
DW_FORM_block1; in fact, it does not emit *anything* where the
DW_AT_const_value is expected. This causes the resulting debug info to be
corrupted, and tools operating on this info will emit errors (or even crash).
On ppc64le-linux (but not x86_64-linux), the same problem occurs with GCC 5 as
well. The difference seems to be that x86_64 in GCC 5 uses a CONST_DOUBLE
instead of a CONST_WIDE_INT to represent that 128-bit constant.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
@ 2015-07-01 17:48 ` uweigand at gcc dot gnu.org
2015-07-01 17:50 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: uweigand at gcc dot gnu.org @ 2015-07-01 17:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #1 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
A bit of debugging shows that what's going on here is this:
add_const_value_attribute is called with the following constant RTL:
(const_wide_int 0x80000000000000000000000000000000)
The routine then does:
add_AT_wide (die, DW_AT_const_value,
std::make_pair (rtl, GET_MODE (rtl)));
Note that GET_MODE (rtl) is VOIDmode. This apparently causes creation of a
wide_int value with precision 0:
{<wide_int_storage> = {val = {0, -9223372036854775808, 2}, len = 2, precision =
0}
This seems already wrong, but doesn't quite explain the inconsistent output.
However, dwarf2out.c:get_full_len returns 0 if the precision is 0.
Subsequently, when the DIE is emitted in output_die, we have:
int len = get_full_len (*a->dw_attr_val.v.val_wide);
int l = HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR;
if (len * HOST_BITS_PER_WIDE_INT > 64)
dw2_asm_output_data (1, get_full_len (*a->dw_attr_val.v.val_wide)
* l,
NULL);
if (WORDS_BIG_ENDIAN)
for (i = len - 1; i >= 0; --i)
{
dw2_asm_output_data (l, a->dw_attr_val.v.val_wide->elt (i),
"%s", name);
name = NULL;
}
When get_full_len is 0, the "if" is false, and thus no length is emitted. In
addition, the loop count is 0, so nothing is emitted at all.
On the other hand, when the abbrev is emitted, value_format does:
case dw_val_class_wide_int:
switch (get_full_len (*a->dw_attr_val.v.val_wide) *
HOST_BITS_PER_WIDE_INT)
{
case 8:
return DW_FORM_data1;
case 16:
return DW_FORM_data2;
case 32:
return DW_FORM_data4;
case 64:
return DW_FORM_data8;
default:
return DW_FORM_block1;
}
so for a length of 0 we fall into the default case and assume DW_FORM_block1.
Any suggestions how to fix those (two?) problems?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
2015-07-01 17:48 ` [Bug debug/66728] " uweigand at gcc dot gnu.org
@ 2015-07-01 17:50 ` pinskia at gcc dot gnu.org
2015-07-02 7:50 ` [Bug debug/66728] [5/6 Regression] " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-07-01 17:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Related to bug 31690.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
2015-07-01 17:48 ` [Bug debug/66728] " uweigand at gcc dot gnu.org
2015-07-01 17:50 ` pinskia at gcc dot gnu.org
@ 2015-07-02 7:50 ` rguenth at gcc dot gnu.org
2015-07-02 17:22 ` rsandifo at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-07-02 7:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-debug
Target| |ppc64le-*-*, x86_64-*-*
CC| |rsandifo at gcc dot gnu.org
Version|unknown |5.1.1
Target Milestone|--- |5.2
Summary|CONST_WIDE_INT causes |[5/6 Regression]
|corrupted DWARF debug info |CONST_WIDE_INT causes
| |corrupted DWARF debug info
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (2 preceding siblings ...)
2015-07-02 7:50 ` [Bug debug/66728] [5/6 Regression] " rguenth at gcc dot gnu.org
@ 2015-07-02 17:22 ` rsandifo at gcc dot gnu.org
2015-07-02 18:50 ` rsandifo at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2015-07-02 17:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2015-07-02
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #1)
> A bit of debugging shows that what's going on here is this:
>
> add_const_value_attribute is called with the following constant RTL:
> (const_wide_int 0x80000000000000000000000000000000)
>
> The routine then does:
> add_AT_wide (die, DW_AT_const_value,
> std::make_pair (rtl, GET_MODE (rtl)));
>
> Note that GET_MODE (rtl) is VOIDmode. This apparently causes creation of a
> wide_int value with precision 0:
> {<wide_int_storage> = {val = {0, -9223372036854775808, 2}, len = 2,
> precision = 0}
>
> This seems already wrong, but doesn't quite explain the inconsistent output.
Yeah, wide_ints shouldn't have precision 0. I think the later problems
do follow from that, although like you say there is probably a disconnect
between the way the DIEs are handled as well.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (3 preceding siblings ...)
2015-07-02 17:22 ` rsandifo at gcc dot gnu.org
@ 2015-07-02 18:50 ` rsandifo at gcc dot gnu.org
2015-07-16 9:18 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2015-07-02 18:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Testing a patch. It involves tightening the mode of the rtx returned
by rtl_for_decl_location, as well as new asserts, so some fallout is
likely...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (4 preceding siblings ...)
2015-07-02 18:50 ` rsandifo at gcc dot gnu.org
@ 2015-07-16 9:18 ` rguenth at gcc dot gnu.org
2015-08-20 12:00 ` uweigand at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-07-16 9:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.2 |5.3
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (5 preceding siblings ...)
2015-07-16 9:18 ` rguenth at gcc dot gnu.org
@ 2015-08-20 12:00 ` uweigand at gcc dot gnu.org
2015-08-20 20:57 ` rsandifo at gcc dot gnu.org
2021-03-22 7:53 ` [Bug debug/66728] [5 " cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: uweigand at gcc dot gnu.org @ 2015-08-20 12:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #6 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #4)
> Testing a patch. It involves tightening the mode of the rtx returned
> by rtl_for_decl_location, as well as new asserts, so some fallout is
> likely...
Hi Richard, just a quick ping ... Were you able to make any progress with
this?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (6 preceding siblings ...)
2015-08-20 12:00 ` uweigand at gcc dot gnu.org
@ 2015-08-20 20:57 ` rsandifo at gcc dot gnu.org
2021-03-22 7:53 ` [Bug debug/66728] [5 " cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2015-08-20 20:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #6)
> (In reply to rsandifo@gcc.gnu.org from comment #4)
> > Testing a patch. It involves tightening the mode of the rtx returned
> > by rtl_for_decl_location, as well as new asserts, so some fallout is
> > likely...
>
> Hi Richard, just a quick ping ... Were you able to make any progress with
> this?
As expected there was a lot of fallout from trying to tighten the mode.
We just seem to be very loose with our type safety here. Sometimes the
mode of the value associated with the decl is DECL_MODE, sometimes it's
the result of promote_decl_mode, sometimes it's BLKmode when the DECL_MODE
isn't, sometimes the DECL_MODE is BLKmode when the rtl isn't, etc.
It all turned into a bit of a rathole.
I suppose I'm just going to have to admit defeat and use the type or
mode of the decl only in the case where the rtl is a scalar integer
constant -- which seems very inconsistent.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
` (7 preceding siblings ...)
2015-08-20 20:57 ` rsandifo at gcc dot gnu.org
@ 2021-03-22 7:53 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-22 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:fc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954
commit r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Mar 22 08:52:04 2021 +0100
debug: Fix __int128 handling in dwarf2out [PR99562]
The PR66728 changes broke __int128 handling.
It emits wide_int numbers in their minimum unsigned precision
rather than in their full precision.
The problem is then that e.g. the DW_OP_implicit_value path:
int_mode = as_a <scalar_int_mode> (mode);
loc_result = new_loc_descr (DW_OP_implicit_value,
GET_MODE_SIZE (int_mode), 0);
loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc<wide_int> ();
*loc_result->dw_loc_oprnd2.v.val_wide = rtx_mode_t (rtl,
int_mode);
emits invalid DWARF. In particular this patch fixes there multiple
occurences of:
.byte 0x9e # DW_OP_implicit_value
.uleb128 0x10
.quad 0xffffffffffffffff
+ .quad 0
.quad .LVL46 # Location list begin address (*.LLST40)
.quad .LFE14 # Location list end address (*.LLST40)
where we said the value has 16 byte size but then only emitted 8 byte
value.
My understanding is that most of the places that use val_wide expect
the precision they chose (the one of the mode they want etc.), the only
exception is the add_const_value_attribute case where it deals with
VOIDmode CONST_WIDE_INTs, for that I agree when we don't have a mode
we need to fallback to minimum precision (not sure if maximum of
min_precision UNSIGNED and SIGNED wouldn't be better, then consumers
would know if it is signed or unsigned by looking at the MSB),
but that code already computes the precision, just decided to
create the wide_int with much larger precision (e.g. 512 bit
on x86_64).
2021-03-22 Jakub Jelinek <jakub@redhat.com>
PR debug/99562
PR debug/66728
* dwarf2out.c (get_full_len): Use get_precision rather than
min_precision.
(add_const_value_attribute): Make sure add_AT_wide argument has
precision prec rather than some very wide one.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-03-22 7:53 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-01 17:39 [Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info uweigand at gcc dot gnu.org
2015-07-01 17:48 ` [Bug debug/66728] " uweigand at gcc dot gnu.org
2015-07-01 17:50 ` pinskia at gcc dot gnu.org
2015-07-02 7:50 ` [Bug debug/66728] [5/6 Regression] " rguenth at gcc dot gnu.org
2015-07-02 17:22 ` rsandifo at gcc dot gnu.org
2015-07-02 18:50 ` rsandifo at gcc dot gnu.org
2015-07-16 9:18 ` rguenth at gcc dot gnu.org
2015-08-20 12:00 ` uweigand at gcc dot gnu.org
2015-08-20 20:57 ` rsandifo at gcc dot gnu.org
2021-03-22 7:53 ` [Bug debug/66728] [5 " cvs-commit at gcc dot gnu.org
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).