[Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- 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 before
> they are initialized, so they try to interpret garbage as values. The
> OverflowError is just because some uninitialized std::string cannot be
> printed.
> 
> 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 all
> before their lifetime has begun, especially not via python printers.
> 
> 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:
> 
> "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 = 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_cfa)
    <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.