[PATCH 17/20] Change die_info methods to check the attribute's form

Simon Marchi simark@simark.ca
Mon Mar 30 20:18:40 GMT 2020


On 2020-03-30 3:04 p.m., Tom Tromey wrote:
> I tend to think gdb complaints are just time-wasters TBH.
> 
> Normally no one examines them.  They aren't visible to users, and if
> they were they wouldn't make sense or be actionable anyway.
> 
> I enable complaints in my gdbinit but they've turned out just to be
> noise.  In fact, last time I fixed a bug that was noted by a complaint,
> it turned out I didn't realize that gdb was complaining until well after
> the fact.

Hmm I didn't even know you had to enable them.  When I debug gdb with gdb, I
see some lines like this:

During symbol reading: Member function "~_Sp_counted_base" (offset 0xbc3e90) is virtual but the vtable offset is not specified
During symbol reading: cannot get low and high bounds for subprogram DIE at 0xbd80c0
During symbol reading: Multiple children of DIE 0xbf6816 refer to DIE 0xbf6804 as their abstract origin

I thought those were complaints.

> I'm all for checking the DWARF output of compilers, but I think it's
> better as a separate tool; and should be done in a context where someone
> actually wants to fix the compiler bugs.
> 
> I guess that's why I left out complaints in some spots.

I agree that there's nothing the users can't do much about those issues, so
we shouldn't flood them with meaningless (for them) warnings.  But I'm also
worried that silently ignoring suspicious situations just leads to problems
staying around for longer.

Though if nobody fixes them, they are not really useful.  I'd like to take
the time to take a look at each complaint of GDB and address it (either fix
GDB or open a bug with the compiler), but the reality is that I don't have
time for that.

I think the patches are fine how they are in this regard, this is an issue
orthogonal to the goal of your patchset anyway.

Simon


More information about the Gdb-patches mailing list