From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id u5gvCfgQ5Wgb9yIAWB0awg (envelope-from ) for ; Tue, 07 Oct 2025 09:09:12 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ojDA77nF; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=MnYXP0MW; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=py8IT+Rs; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=zLBPUypi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 183CC1E047; Tue, 07 Oct 2025 09:09:12 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EE3D01E047 for ; Tue, 07 Oct 2025 09:09:10 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9887C3858C56 for ; Tue, 7 Oct 2025 13:09:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9887C3858C56 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ojDA77nF; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=MnYXP0MW; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=py8IT+Rs; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=zLBPUypi Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 0F6E33858D1E for ; Tue, 7 Oct 2025 13:08:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F6E33858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0F6E33858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759842511; cv=none; b=abgArVHk4USsUaLnW64kRfdM/xc+G6mJvRLNm5gMlDzPjKQJcJwp2VEU4jYFMWFsxIweeVuTVu+CAVxArax4bJ6BE1ZMwiaiyjPTy4UFzGJRRhmes1wehEudC5yInwR8Ny5/EhfqZMbS3TMaaW3LJFzgbiGfcI13kOX6wPIwFYE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759842511; c=relaxed/simple; bh=nG6QZ4fvezrjkbkYIeu5x2B27EufZDiEaXPW1YEtwtw=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=u7G4rqg/n2qAQMs/VgGYN+OkkAgUOxH/Iy2cBt0PkaOU4YxhK5OZOC5vMShi+NWRCMUKjhzGs2Rn+vuDPOUscZ+oTqe25dKs2Nt0r/hy95P/xvbAXJv5EyS6ygNdUfq0O+eXA4d/AyG9mE0N0H6V+926iOoJuoTeFWBirfk9Jzc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0F6E33858D1E Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 0F92F33703; Tue, 7 Oct 2025 13:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1759842510; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LND3S6izBXqyk39qn2/tEsFNm6kLUJmsKjJZbl9z6uw=; b=ojDA77nFDk0IfeQqx3Vm2Qm7W1e5uVSD7QOlt61R0KIKjtGPkQtUaEMJYd1x8Prtp9ROug I3jczFlreVoMpyYIhiQzFUN8XTpBdI3Wtrlx51/P144+S8p0vbmJdvQQBBsbVg1PmNeVU1 FdqbL8b/pLvO4e/teUw0IS1yIDpL1sw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1759842510; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LND3S6izBXqyk39qn2/tEsFNm6kLUJmsKjJZbl9z6uw=; b=MnYXP0MWXob2Lb3ODbue/APXZnSXmGwuWGlTC9t+TDA+HICQHqWjAu5RTdYLK1qnhmUEB8 MBeh9UAV/JT480BQ== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=py8IT+Rs; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=zLBPUypi DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1759842509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LND3S6izBXqyk39qn2/tEsFNm6kLUJmsKjJZbl9z6uw=; b=py8IT+RsISDQkxD1ob5vZ5ChBxWMq7qHJDc8SfpRyGClKsoBFKOnqr0wgQhHXONTL3jIh/ Egsj9mdkQPtU+6wgsA448wQvDi5xAjKOHO/AUK7aj4m/2a8q6U7RVeFjfK01XKlFnK8gAl 7qh4qI/bhh3iFgl4u0Httn21xio0laA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1759842509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LND3S6izBXqyk39qn2/tEsFNm6kLUJmsKjJZbl9z6uw=; b=zLBPUypi+RgZRUyemKxckezJZ3vZsakmI1Zg9EgJCqqki4ZWwf1uMsnvymYhhFFsWigvRM 790D1D2XX2tplRDA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E7DC513693; Tue, 7 Oct 2025 13:08:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id yLE/N8wQ5WhLIAAAD6G6ig (envelope-from ); Tue, 07 Oct 2025 13:08:28 +0000 Message-ID: Date: Tue, 7 Oct 2025 15:08:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method To: Andrew Burgess , Tom Tromey Cc: gdb-patches@sourceware.org References: <9ab589510f784da2752b72d0b1385afa33aca406.1758634958.git.aburgess@redhat.com> <87cy737q50.fsf@tromey.com> <87zfa26gxp.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: <87zfa26gxp.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0F92F33703 X-Rspamd-Action: no action X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; URIBL_BLOCKED(0.00)[suse.de:dkim,suse.de:mid,suse.de:email,tromey.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:url]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; DWL_DNSWL_BLOCKED(0.00)[suse.de:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCPT_COUNT_THREE(0.00)[3]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns, imap1.dmz-prg2.suse.org:helo, suse.com:url, suse.de:dkim, suse.de:mid, suse.de:email] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 10/7/25 14:21, Andrew Burgess wrote: > Tom de Vries writes: > >> On 10/3/25 21:15, Tom Tromey wrote: >>> Andrew> Add a new Corefile.mapped_files method which returns a list of >>> Andrew> gdb.CorefileMappedFile objects. >>> >>> Andrew> Each gdb.CorefileMappedFile object represents a file that was mapped >>> Andrew> into the process when the core file was created. >>> >>> Andrew> + ** New Inferior.corefile attribute. This read only attribute >>> Andrew> + contains the gdb.Corefile object if a core file is loaded into >>> Andrew> + the inferior, otherwise, this contains None. >>> >>> This hunk is duplicated, it also appears in patch 1. >>> >>> Other than that this looks good to me. >>> Approved-By: Tom Tromey >> >> Hi, >> >> Starting with this commit, I see: >> ... >> (gdb) check-build-ids^M >> Python Exception : build-id mismatch for >> /lib64/libc.so.6^M >> Error occurred in Python: build-id mismatch for /lib64/libc.so.6^M >> (gdb) FAIL: gdb.python/py-corefile.exp: test mapped files data: >> check-build-ids >> ... > > So that test is checking that the build-ids of the objfiles that were > loaded match the build-ids pulled from the corefile. > > For example, GDB should find a build-id for `/lib64/libc.so.6` in the > core file, then when GDB loads `/lib64/libc.so.6` an objfile is created, > we can also read the build-id via the objfile. > > The failure tells us that for some reason these two methods to read the > build-id gave different results. > > Now, `/lib64/libc.so.6` must have a build-id, otherwise the objfile > would return None for its build-id, and the check-build-ids command > would ignore this library and we shouldn't see an assert. > > So for the assert to trigger one of these things must have happened: > > + Build-id is present in the core file, but GDB failed to extract it, > or extracted the wrong data. Resulting in either None, or a different > build-id, or > > + Build-id is not present in the core file, GDB will return None for > the build-id. > > Of these two I suspect the second; for a period of time the GNU linker > was ... changed ... such that it no longer placed the build-id within > the first page of a generated ELF, as a result, the Linux kernel would > not include the build-id in core dumps. > > We can check for the second case using: > > readelf -WS /lib64/libc.so.6 | grep build-id > > The output will be something like: > > [ 2] .note.gnu.build-id NOTE 0000000000000370 000370 000024 00 A 0 0 4 > > It's the '000370' column we're interested in. If this value is greater > than a page size, then GDB isn't going to be able to find the build-id. > Hi Andrew, it seems to be the second case indeed: ... $ readelf -WS /lib64/libc.so.6 | grep build-id [22] .note.gnu.build-id NOTE 00000000001fa178 1fa178 000024 00 A 0 0 4 ... Sofar, I've only encountered this problem on Tumbleweed ( https://bugzilla.suse.com/show_bug.cgi?id=1240689 ), this is the first test-case for which I run into it on Leap 15.6. But they have the same linker base version: 2.43.1 (though soon to be upgraded, AFAIU), so that makes sense. > You could try applying the patch below. This isn't a real fix, but does > two things: > > 1. Ignores any None build-id values pulled from the core file. I > suspect this will be enough to get the test passing for you, but > the patch also does > > 2. prints both build-ids if there is a mismatch. > > Unfortunately just doing (1) isn't a long term fix as this would also > ignore the case where a bug in GDB means that we fail to find the > build-id. > Ack. > So what I'm going to do is try to extend the test so that we can use > maybe readelf like I show above to check if GDB _should_ be able to find > the build-id, and only run the build-id check _if_ we think GDB should > be able to find the build-ids. > FWIW, there are a few other test-cases that could benefit from such a mechanism as well. > Anyway, I'd be interested to hear if the patch resolves the failure for > you. If it doesn't then I'm on completely the wrong path and will need > to rethink. The patch does fix this. And FWIW, reverting part 1 gives us: ... (gdb) check-build-ids^M Python Exception : build-id mismatch for /lib64/libc.so.6; 16dc6ffdd6165c6cb0346d683a041c90daa99730 vs None^M Error occurred in Python: build-id mismatch for /lib64/libc.so.6; 16dc6ffdd6165c6cb0346d683a041c90daa99730 vs None^M (gdb) FAIL: $exp: test mapped files data: check-build-ids ... Thanks, - Tom > Thanks, > Andrew > > --- > > diff --git i/gdb/testsuite/gdb.python/py-corefile.py w/gdb/testsuite/gdb.python/py-corefile.py > index cffd037a23b..979a0281d12 100644 > --- i/gdb/testsuite/gdb.python/py-corefile.py > +++ w/gdb/testsuite/gdb.python/py-corefile.py > @@ -101,9 +101,12 @@ class CheckBuildIds(gdb.Command): > p = pathlib.Path(m.filename).resolve() > b = m.build_id > > + if b is None: > + continue > + > if p in path_to_build_id: > count += 1 > - assert path_to_build_id[p] == b, "build-id mismatch for %s" % p > + assert path_to_build_id[p] == b, "build-id mismatch for %s; %s vs %s" % (p, path_to_build_id[p], b) > > assert count > 0, "no mapped files checked" > >