From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14975 invoked by alias); 28 May 2018 03:04:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14948 invoked by uid 89); 28 May 2018 03:04:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=worthwhile, Consider, locating X-HELO: gateway34.websitewelcome.com Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.148.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 May 2018 03:04:35 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway34.websitewelcome.com (Postfix) with ESMTP id E23E7FB8493 for ; Sun, 27 May 2018 22:04:33 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id N8SXf3UYz79N3N8SXfZEJC; Sun, 27 May 2018 22:04:33 -0500 X-Authority-Reason: nr=8 Received: from 174-29-44-154.hlrn.qwest.net ([174.29.44.154]:46732 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fN8SX-001dUT-MU; Sun, 27 May 2018 22:04:33 -0500 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 0/9] Radically simplify the complaint system References: <20180522050704.10845-1-tom@tromey.com> <190d88e2-35a5-9dc2-8b28-4a8c37e0617a@redhat.com> <87d0xmfodf.fsf@tromey.com> Date: Mon, 28 May 2018 10:41:00 -0000 In-Reply-To: (Pedro Alves's message of "Wed, 23 May 2018 16:08:28 +0100") Message-ID: <8736yczdj3.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fN8SX-001dUT-MU X-Source-Sender: 174-29-44-154.hlrn.qwest.net (bapiya) [174.29.44.154]:46732 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-05/txt/msg00727.txt.bz2 >>>>> "Pedro" == Pedro Alves 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