From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AE03F385C017 for ; Mon, 30 Mar 2020 20:18:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE03F385C017 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 332D81E4C2; Mon, 30 Mar 2020 16:18:41 -0400 (EDT) Subject: Re: [PATCH 17/20] Change die_info methods to check the attribute's form To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20200328192208.11324-1-tom@tromey.com> <20200328192208.11324-18-tom@tromey.com> <331c3446-c38b-49f6-f185-61eabed36502@simark.ca> <87mu7xfyvm.fsf@tromey.com> From: Simon Marchi Message-ID: <3acb4595-0527-b94a-418f-dffae59da65e@simark.ca> Date: Mon, 30 Mar 2020 16:18:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <87mu7xfyvm.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 20:18:42 -0000 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