public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
Subject: Re: [RFA 0/9] Radically simplify the complaint system
Date: Mon, 28 May 2018 10:41:00 -0000	[thread overview]
Message-ID: <8736yczdj3.fsf@tromey.com> (raw)
In-Reply-To: <f9db811c-9a77-fd41-91bd-186aa4e63844@redhat.com> (Pedro Alves's	message of "Wed, 23 May 2018 16:08:28 +0100")

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> 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.

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

Curious.

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

Now that is even more curious.  I can't interrupt debug info reading at
all.  And, this is what I'd expect, because the only QUIT in
dwarf2read.c is in dw_expand_symtabs_matching_file_matcher, which is
only used during CU expansion, not the initial read.

So I wonder why this works for you.

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

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

I looked at this a bit.  There are two issues.

One is that the generic reader code (or whatever asks for psymtab
expansion, etc) does not know the name of the symbol reader it is
calling.  So, there's no convenient way to print "DWARF" there.

Second, in some cases the relevant module name isn't what is generically
available.  Consider read_comp_unit_head, which does:

  const char *filename = get_section_file_name (section);
...
	  complaint (_("debug type entry at offset %s is duplicate to"
		       " the entry at offset %s, signature %s"),
		     sect_offset_str (sect_off), sect_offset_str (dup_sect_off),
		     hex_string (header.signature));

Here, the file name might be the dwz file, or maybe some dwo file (I
don't know), depending on where the section originated.


So, for the time being, I plan to just tidy up the output a bit without
changing it too much.  Maybe one idea would be to remove the
SHORT_FIRST_MESSAGE case from complaints.c and just have every message
start "During symbol reading".  This would at least be explicit.


I do think it would be worthwhile to go through all the DWARF complaints
and fix them up to include the relevant locating information.

For example, bad call:

	  complaint (_("location description stack underflow"));

This is bad since there's no convenient way to find the offending DIE.
In the past I've debugged gdb to find these.

Good call:

	  complaint (_("compilation unit with DW_AT_GNU_dwo_name"
		       " has children (offset %s) [in module %s]"),
		     sect_offset_str (this_cu->sect_off),
		     bfd_get_filename (abfd));

Though, it occurs to me that going through all of them to include this
info would tend to work against the idea of some more generic fix.

Tom

  reply	other threads:[~2018-05-28  3:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22  5:09 Tom Tromey
2018-05-22  5:07 ` [RFA 2/9] Remove elements from complaint_series Tom Tromey
2018-05-22  5:07 ` [RFA 9/9] Remove struct complaints Tom Tromey
2018-05-22  5:08 ` [RFA 6/9] Remove vcomplaint Tom Tromey
2018-05-22  5:08 ` [RFA 5/9] Remove struct explanation Tom Tromey
2018-05-22  5:09 ` [RFA 4/9] Remove symfile_complaints Tom Tromey
2018-05-22  5:09 ` [RFA 1/9] Remove internal_complaint Tom Tromey
2018-05-22  5:09 ` [RFA 8/9] Remove struct complain Tom Tromey
2018-05-22  5:50 ` [RFA 3/9] Remove "noisy" parameter from clear_complaints Tom Tromey
2018-05-22  7:01 ` [RFA 7/9] Remove file and line from struct complain Tom Tromey
2018-05-23 14:49 ` [RFA 0/9] Radically simplify the complaint system Pedro Alves
2018-05-23 15:08   ` Tom Tromey
2018-05-23 17:44     ` Pedro Alves
2018-05-28 10:41       ` Tom Tromey [this message]
2018-05-28 10:41         ` Tom Tromey
2018-05-28 19:37         ` Pedro Alves
2018-05-28 22:19           ` Tom Tromey
2018-05-29 16:05             ` Pedro Alves
2018-06-04 20:25 ` Possible regression on gdb.gdb/complaints.exp (was: Re: [RFA 0/9] Radically simplify the complaint system) Sergio Durigan Junior
2018-06-04 21:38   ` Possible regression on gdb.gdb/complaints.exp Tom Tromey
2018-06-04 23:29     ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736yczdj3.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).