From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CBC4F381D469; Mon,  5 Dec 2022 08:45:57 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CBC4F381D469
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670229957;
	bh=FjtvrduylYvfvT/PhK5MS6F03ezRIm19diOUK9lvq9k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=whBoj33bm9sPiPx3AGARiiYhtC8hY2t6I2BIQQtLC/9c2p607dswTNMurYCR8Sbms
	 XaB/cAkKUFB9/EIETpv6829XtfLQ/PxNrsFWeMVwAkbF8Y77XUpr2JAL8zbe/Krk5S
	 5R8m8sEwOSfiLfHXDT2DWk5JykPpRi8rkW7o/Iag=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many
 Exceptions From Uninitialized Structures
Date: Mon, 05 Dec 2022 08:45:57 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107965-4-JB1f57a5S3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107965-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107965-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> They're nothing the printers can do. You're asking to print them out befo=
re
> they are initialized, so they try to interpret garbage as values. The
> OverflowError is just because some uninitialized std::string cannot be
> printed.
>=20
> This should really be reported as a gdb bug. Gdb knows if the object's
> initialization had finished, so it should not try to print variables at a=
ll
> before their lifetime has begun, especially not via python printers.
>=20
> It might make sense to display the variable name with a value like <before
> lifetime>, but even that is debatable. The C++ standard is very clear that
> none of those variables exists yet at your breakpoint, and gdb contradicts
> its own documentation:
>=20
> "These are all variables (declared either static or automatic) accessible=
 at
> the point of execution of the selected frame."

I'm not so sure.  For

struct X { X(); int i; };

X::X () { i =3D 42; }

int main()
{
  X x;
  return 0;
}

GCC emits

 <1><6e>: Abbrev Number: 9 (DW_TAG_subprogram)
    <6f>   DW_AT_external    : 1
    <6f>   DW_AT_name        : (indirect string, offset: 0xf): main
    <73>   DW_AT_decl_file   : 1
    <74>   DW_AT_decl_line   : 5
    <75>   DW_AT_decl_column : 5
    <76>   DW_AT_type        : <0x67>
    <7a>   DW_AT_low_pc      : 0x15
    <82>   DW_AT_high_pc     : 0x1b
    <8a>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_c=
fa)
    <8c>   DW_AT_GNU_all_tail_call_sites: 1
    <8c>   DW_AT_sibling     : <0x9e>
 <2><90>: Abbrev Number: 10 (DW_TAG_variable)
    <91>   DW_AT_name        : x
    <93>   DW_AT_decl_file   : 1
    <94>   DW_AT_decl_line   : 7
    <95>   DW_AT_decl_column : 5
    <96>   DW_AT_type        : <0x2d>
    <9a>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)

so gdb has no idea that x only becomes live after the call to the CTOR
(or during that).  Instead GCC says it lives throughout the whole
function on the frame.  Even the original IL from the frontend has no
hint that would allow the middle-end to emit different DWARF.=