From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id E0rLCkUV5Wjd+iIAWB0awg (envelope-from ) for ; Tue, 07 Oct 2025 09:27:33 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RR8osHrf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1F21C1E047; Tue, 07 Oct 2025 09:27:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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 547381E047 for ; Tue, 07 Oct 2025 09:27:32 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 87A793858C31 for ; Tue, 7 Oct 2025 13:27:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 87A793858C31 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RR8osHrf Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 976CE3858D1E for ; Tue, 7 Oct 2025 13:26:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 976CE3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 976CE3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759843613; cv=none; b=ivYtQ0/ahSdEBW5g1SXUJ9hdgq1C2zOWdSGfxagdjVCoxqCyAN0ZLoZroa93sGvC31GfxHiQaC5GNrgXCKdVlIN4TSEpvXfvKRxUM8UpiO2KoKRXa9TMKBURLpBHPODYEWnvTNG1NzInS9F83n/GhEynvTBbo9kpfInRRJtC9ZU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759843613; c=relaxed/simple; bh=2ryysGBnaMsmBkPcxSb+qt2pO+TgN+CEu0pHvpCU+sA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=fpnPgJGyLVDQXSZq/V5Q+qXNtj8H05ZLW/VbtWLSEhM+eVkSazVFAKDR2jhjlH9vJo1i57pIsYPNFhQ88lALJZ1mW/EFblnfTGPQZ2HT+pg2oFO6K1ECLwZK2Fm0JKJUCI8DIM5Fttm6k+k1dvJDA3N7TGTxki9q15fQvF5CN/k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 976CE3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759843613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MJ9rjyfRQclwBB9iMsaXUV/yjcyUwwvGXdcgKEWoiY4=; b=RR8osHrfCqP7f+2WXx/FyH8rRwNuc/n5zB/WTNwhwxmC67jxpX38IwATaDE/b9jDFL3EyP zPprEixsENMLygDOySvR+Uv9WfjhSIkoTwkezo+UGHaVtD9NSYvZuh3Ig/X72ZZ+g/88lL uLdMngQYmZQ4TQHM2VMmDVP8EscJoSE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-256-F4lxMHXIMv-YFOHTBVLe-w-1; Tue, 07 Oct 2025 09:26:51 -0400 X-MC-Unique: F4lxMHXIMv-YFOHTBVLe-w-1 X-Mimecast-MFC-AGG-ID: F4lxMHXIMv-YFOHTBVLe-w_1759843610 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-46e36686ca1so61249965e9.2 for ; Tue, 07 Oct 2025 06:26:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759843610; x=1760448410; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MJ9rjyfRQclwBB9iMsaXUV/yjcyUwwvGXdcgKEWoiY4=; b=hXoAFQjxW86Ugl85K/LeS9pSnq/zzQfkVgRfT56C1FojwfymQrVV2oczF4rRfd6jq+ TsVAjgElLVyL5fUWJ8WTTTvred5U561ocQyf7QaIYDxt4k7JjkGc10WmOUjAHLsUCTWL e550/jDz691rMCHLGZFgiX3jR4ugeTlYx4LCjSTKZA5C5SbuSdv/b0Y7wPAUJBtHo1MW rKro1SuyNcuPA8Eb9L9X/V06MO3mk1xH2JPgKNz2x6rYa5FvPxHbG8vLTtesdhFYWs4V 47t0zzwAOrzfkyNRaD6yYVXZgO3TCzLkL3QYyHhJfi8yIqY3aa84xiFwNLJSlxw8ZRFY gFbw== X-Gm-Message-State: AOJu0YyvOK5P0b/uafzSo1l4fX9PDvQbC4DY9CbBeDifjCTiGEpp3Hgg h9KLV8cwv3+mzmHU4SUerAtQ3nQhE3HzbZ40kprAm0wcrQ9DdGdBzBNiM5VvwBbUCpmtGJG3MiH 4B64YVddHMEK2BAvBRTUUeDb6/WpaM3UQoPKNiz99h1MJlFbuzSIGJxQRljof3pc= X-Gm-Gg: ASbGnct5NL9cJHy9oy0zoOPAQsS5yTq/6aDz7oeycVYcWaxGljoY4LDg/g2LftMK+oU gHqDyeTb1+G4SsDU/A0k+DE6Q+3+6Ni/m7VTocToiZqTIG7R9uTAFyJrYxhKKuksRn4GoImxNBv NN7XOsWllVsGrISL25SvgMvd46qo/gZdNtwtuR9MeHMexmmTyp+KVTIiG0TNE89fDHBNaJUXq4/ cFI1KivxoTec1M4tyIceYAJiwSoJNpQeF/h7WJiFLNnix0nApiQ/255XjoP1pvEBRpYhC6QjlFC jrlH2LeHMdHIXdyfPvAB2T++EahOQgaolh9uK/Kd X-Received: by 2002:a05:600c:8506:b0:46e:1fb9:5497 with SMTP id 5b1f17b1804b1-46e7113f6e2mr118416115e9.18.1759843610065; Tue, 07 Oct 2025 06:26:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGi2b70KB1CI/0knWQaPO7qBrj4E/t/IhNJu8NZu0b6jRJhRfy7KVkl5uF65yDeVepo5i4p1g== X-Received: by 2002:a05:600c:8506:b0:46e:1fb9:5497 with SMTP id 5b1f17b1804b1-46e7113f6e2mr118415845e9.18.1759843609509; Tue, 07 Oct 2025 06:26:49 -0700 (PDT) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4255d8a6b77sm25511459f8f.6.2025.10.07.06.26.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 06:26:48 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method In-Reply-To: References: <9ab589510f784da2752b72d0b1385afa33aca406.1758634958.git.aburgess@redhat.com> <87cy737q50.fsf@tromey.com> <87zfa26gxp.fsf@redhat.com> Date: Tue, 07 Oct 2025 14:26:48 +0100 Message-ID: <87o6qi6dwn.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 7SST16XTYyXf4wIHkZuVZxKSpccd6DDwJxwDkZ8tiVI_1759843610 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom de Vries writes: > 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 for the diagnostic help. I'll work on improving the test to try and catch these cases. If that works, then we might be able to adopt this to help with other tests. Keeping this in mind, I'll add helper functions to lib/gdb.exp. Thanks, Andrew