From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=vDdf=E5=suse.de=tdevries@sourceware.org>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d])
	by sourceware.org (Postfix) with ESMTPS id 167A63858436
	for <gdb-patches@sourceware.org>; Wed, 13 Sep 2023 14:37:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 167A63858436
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512)
	(No client certificate requested)
	by smtp-out2.suse.de (Postfix) with ESMTPS id 114091F45B;
	Wed, 13 Sep 2023 14:37:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1694615868; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Meo1ANGHW30eSzSHE2UUX4Q8U5v8RdIi8hWqYT92Adk=;
	b=LcFa/R7ao3rIqkcUMYteou+CRz22dw+hfmTPoez89GeTOQ9EW8SVxJoWFkZHF6NihVEDe5
	VKOGENXtae2/UnGPd7IkQYSVHGeuxQTnr48VfRzlg9UWbL/Hewhyi6rZg+JWSVfXTFFk28
	egvuW31Q44lLpI5bvzAFNzyXkrESIUc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1694615868;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Meo1ANGHW30eSzSHE2UUX4Q8U5v8RdIi8hWqYT92Adk=;
	b=DttXKrD2STYdlUVY68XmFpFleHZaxVMDpdTFppWLBVq69/tQP/idttrUkwsRNimWAyCdTm
	m72ftGqH8LWOMWBQ==
Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512)
	(No client certificate requested)
	by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E7C6413582;
	Wed, 13 Sep 2023 14:37:47 +0000 (UTC)
Received: from dovecot-director2.suse.de ([192.168.254.65])
	by imap2.suse-dmz.suse.de with ESMTPSA
	id m+RkNzvJAWUdaAAAMHmgww
	(envelope-from <tdevries@suse.de>); Wed, 13 Sep 2023 14:37:47 +0000
Message-ID: <10881561-aeb1-4aef-a057-7bdddb71802d@suse.de>
Date: Wed, 13 Sep 2023 16:37:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC 0/7] [gdb/symtab, cc-with-dwz] Fix
 gdb.cp/breakpoint-locs.exp
Content-Language: en-US
From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tom@tromey.com>,
 Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
References: <20230825155546.19617-1-tdevries@suse.de>
 <87edj8lcj0.fsf@tromey.com>
In-Reply-To: <87edj8lcj0.fsf@tromey.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gdb-patches.sourceware.org>

On 9/12/23 17:23, Tom de Vries wrote:
> But that does not address the parent entry calculation.  In the simplest 
> case, the parent of an entry is the DIE parent, and it's trivial to 
> handle.  In case the DIE parent is ignored, and the parent is derived by 
> following abstract_origin chains, and we end up with a parent that is 
> not processed yet, we simply have to defer.  And if the parent is in 
> another shard, we have to defer until after the parallel for (or 
> alternatively, wait for other shards to be done, though I'm not sure 
> that level of complexity is worth it).
> 
> The problem of incorrect parent entry calculation is not very visible 
> atm.  If the parent entry calculation is incorrect, it quietly defaults 
> to no parent.  And most of the time, that doesn't result in incorrect 
> gdb behaviour.  This test-case is the exception.  Which we can work 
> around by handling PUs differently.  But we'll still quietly calculate 
> incorrect parent entries, unless we fix the generic case, as this patch 
> series proposes to do.

I managed to write a test-case that demonstrates this problem 
independently of the gdb.cp/breakpoint-locs.exp test-case, filed here ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=30846 ).

Thanks,
- Tom