[RFA 0/9] Radically simplify the complaint system

Pedro Alves palves@redhat.com
Wed May 23 17:44:00 GMT 2018


On 05/23/2018 03:17 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> Can you give an example case of when do we still need or want
> Pedro> the ISOLATED_MESSAGE vs SHORT_FIRST_MESSAGE distinction?
> 
> Sure.  You can see it using:
> 
> $ ./gdb -nx
> (gdb) set complaints 1
> (gdb) file ./gdb
> 
> I get:
> 
>     Reading symbols from ./gdb...DW_AT_low_pc 0x0 is zero for DIE at 0x1717ad8 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0xa6284 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...done.
> 
>     ... stuff here ...
> 
>     During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
>     During symbol reading, const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0.
> 
> 
> What's happening here is that the SHORT_FIRST_MESSAGE stuff is printed
> during the "Reading symbols...", and then once psymtabs are read, we hit
> a call to clear_complaints.  Any subsequent complaints -- say, during
> psymtab expansion -- are issued as ISOLATED_MESSAGE.

Ah, OK.  I don't get those SHORT_FIRST_MESSAGE ones here, lucky me.

I do get them if I interrupt debug info reading with ctrl-c, eh:

Reading symbols from ./gdb...^Cdone.
Quit
Setting up the environment for debugging gdb.
unsupported tag: 'DW_TAG_unspecified_type'...debug info gives source 58 included from file at zero line 0...debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1...Breakpoint 1 at 0x63811a: file /home/pedro/gdb/binutils-gdb/src/gdb/common/errors.c, line 54.
const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0...Member function "~_Sp_counted_base" (offset 0x422925) is virtual but the vtable offset is not specified...cannot get low and high bounds for subprogram DIE at 0x42b8d6...Child DIE 0x443665 and its abstract origin 0x443601 have different parents...Multiple children of DIE 0x445e71 refer to DIE 0x445e60 as their abstract origin...Breakpoint 2 at 0x475d2c: file /home/pedro/gdb/binutils-gdb/src/gdb/cli/cli-cmds.c, line 197.
(top-gdb) 

I've thought before that those several complaints printed in the same
line were very confusing to read.  I wouldn't miss not-having-newlines
at all.

> 
> I have some more patches to try to clean some of this up as well, but I
> thought it would be better to submit this series as a simple complaint
> cleanup rather than trying to change the output at the same time.

That's reasonable.  The patch is fine with me to merge as is.

> 
> What I have so far still preserves this distinction, so this would be a
> good time to talk about what should be done.  All I really did is add
> some newlines and remove the "done." text, so that the "Reading symbols"
> output is cleaner, like:
> 
>     Reading symbols from ./gdb...
>     DW_AT_low_pc 0x0 is zero for DIE at 0x1717ad8 [in module /home/tromey/gdb/build/gdb/gdb]
>     debug_line address at offset 0xa6284 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
> 
> This is a bit weird sometimes still, because some of the complaints are
> rather uninformative, e.g.:
> 
> 	  complaint (&symfile_complaints,
> 		     _("location description stack overflow"));
> 
> I do think it would be good to be able to remove the *_MESSAGE
> constants, I'm just not sure exactly what to print.  Probably I'm just
> overthinking it since I doubt anyone except gdb developers enable
> complaints.

Yeah, why would a user want them?

I wonder whether printing the module name first, maybe also a context
prefix, before the complaint message would make it a little bit nicer.
Something like:

Reading symbols from ./gdb...
DWARF reader: /home/tromey/gdb/build/gdb/gdb: DW_AT_low_pc 0x0 is zero for DIE at 0x1717ad8
DWARF reader: /home/tromey/gdb/build/gdb/gdb: debug_line address at offset 0xa6284 is 0

Thanks,
Pedro Alves



More information about the Gdb-patches mailing list