From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ad9kJmYU8mge4DsAWB0awg (envelope-from ) for ; Fri, 17 Oct 2025 06:03:18 -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=bNhopmlH; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 99D8E1E0BA; Fri, 17 Oct 2025 06:03:18 -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 EB08D1E04C for ; Fri, 17 Oct 2025 06:03:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 234CA3857BBA for ; Fri, 17 Oct 2025 10:03:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 234CA3857BBA 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=bNhopmlH Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 60428385800F for ; Fri, 17 Oct 2025 10:02:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60428385800F 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 60428385800F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760695367; cv=none; b=Y/mVJ/Z5LwSxWNEiczRxSNOlLNvQe1kJa3m9ebalLTgCO+iIZ4zS9TU1Bq0PCz4s4Sh2PmU2BPRiQNq8LODEb03bcqrxX1GsKSaB/Pkx+kJ9VlE9/drVIXKxzCpcEwORCdxgcnnuTFwHRigootIm5ruIKWavWOGf9Ouik7n2byA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760695367; c=relaxed/simple; bh=OPacvUhsz2Iaukb+DvWPKsm6Ur33jOfnGMmEpCpyuTE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hA/Q+4ImnAt/aAKe6zTozeLpMfKpDTy8I3MWrn1hXD/0DhJ+sGh1JbtNaffxJQhQlThIV641HPRaHy/BZXf2dI9+0tImf1d3kfuOlZNyF4SGEdwq73rY8Fq2X9QtTgFZdY/tBWUPxT/UCPKs2BAYKMGYaBN+UdqXjacugmJtN/Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60428385800F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1760695367; 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=Y95lbvSiwwYWiiJ0xhE6zFpez2zeeF+dhEN8+L50Erw=; b=bNhopmlHYAEKEw0PUwWoCMDtykNOi7EOR68fhUALXELXdv0Km4GGYxuUNUgK2v4Xo8JUL9 8ThSsI04a3cNJ0kvVhXvfzWYW9LxfH2pDHm8B3+PibLx8A3cXy21gOUuypzGBnhRFmm7z6 oeHii/SXU8hlrkpYyWFS7dH4sam5lOI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-439-LsdVxVeyNTOE4yiC-tLaHA-1; Fri, 17 Oct 2025 06:02:45 -0400 X-MC-Unique: LsdVxVeyNTOE4yiC-tLaHA-1 X-Mimecast-MFC-AGG-ID: LsdVxVeyNTOE4yiC-tLaHA_1760695365 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-470ffd40c16so7589175e9.3 for ; Fri, 17 Oct 2025 03:02:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760695364; x=1761300164; 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=Y95lbvSiwwYWiiJ0xhE6zFpez2zeeF+dhEN8+L50Erw=; b=tTC5YnP2l8FP57wWEHI8mr2wk7TrLlEMLfijAWhLKymWbcEXCvF1pPXMF4KJcP6SZR fX32EBXgqu84/pDZ2AMShgUFla2bzoTJaMLaqRMjxUGGVFsMirqGn/s1rWiJoafGjeXK jbx6UQvsW9FN/PO3cSdaCHzCxn7/m8vMjTpB7veljCMKOKT39zNe618Uc8Dfrs9mYqRa VmgUCK4WDWgtUW+jycjfuHOsVONz83YZTDB6JINQ+bB6IFGFJ3DNFoT+SQj5D5KbGeCu 1137HaElebLikRI8TGV7W7A86hPhDoTblOqeWsHsx2O9z5ZCcTLEYXv4Dl25S3eobvlV 7i7A== X-Forwarded-Encrypted: i=1; AJvYcCWg6AAZEpwMNwNk6PVnetxuEtRa586PFihEv+0icZB7/cEQQOF7l78TrvUU7g1eKsWoMJslt09wobUjWw==@sourceware.org X-Gm-Message-State: AOJu0YwkuzRfBB8RkLHmk4swDd8SfXzxNh8/Br/nHmrGajE+JxuiDBwB BFPTqak3Gg+wGDuwTnPlK6DaUoN2LNW9Vup+HGgJNpzi3wKvRwAEFfW7AfPb2cEDtbQshmQWqub O6tiWXAq4iKYA/IAE3Y+nd3g+Cadc918oh1aN3haboBUFhciTXc8z9fVuwne6HH9pVlmJtZk= X-Gm-Gg: ASbGncuXynXCX5HpOO6EcRyTRKABJYwyp/vl7Q6ZOgVJeXdilWE2wVMHxdV0MzjJdeK mzVOIc4g70nN9ei1Qjr7u7WhBAZ8v2t2TQb3BkSn1ryESQ3+0O8hrHchr4rRbSScWnk/14JcfUH jvf5YcT670xSUIgBQIbZnIbi8+56yF2sOA37BhTkqF9AWIYJ3Jdkk0ixB6nMRhjlce5SjkVRnyX sbW80ukz7TCQclalkXvPVy8ZVeA7KgXaUd56OWdgH+XVulxmIJQWlgtHM4eO9PQ6qXmwxrKvtMh ezjHYER1B/YSdPTn5Ej7pabTazmMOrmytEidF4vpdu0KoJfYZMaD5ETIX7kGmWQ2/SeZVw== X-Received: by 2002:a05:600d:824d:b0:471:1b25:f9ff with SMTP id 5b1f17b1804b1-4711b25fcefmr7371765e9.39.1760695364270; Fri, 17 Oct 2025 03:02:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHp7/Gsmk9cEYxL0JPKW/gHodRvnWjdRuo0IpbOIw2QuEY0YovbTKZqPDpawYiBpJRq7txLHg== X-Received: by 2002:a05:600d:824d:b0:471:1b25:f9ff with SMTP id 5b1f17b1804b1-4711b25fcefmr7371505e9.39.1760695363745; Fri, 17 Oct 2025 03:02:43 -0700 (PDT) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-471144b5c34sm81530785e9.10.2025.10.17.03.02.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Oct 2025 03:02:43 -0700 (PDT) From: Andrew Burgess To: Tom Tromey Cc: Tom de Vries , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method In-Reply-To: <87o6q6r514.fsf@tromey.com> References: <9ab589510f784da2752b72d0b1385afa33aca406.1758634958.git.aburgess@redhat.com> <87cy737q50.fsf@tromey.com> <87zfa26gxp.fsf@redhat.com> <87o6q6r514.fsf@tromey.com> Date: Fri, 17 Oct 2025 11:02:42 +0100 Message-ID: <87sefhalrx.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: juKm6Tt7AXuCVnKDb5ApHcO0whmujuGPExWaFBdMN70_1760695365 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 Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> + Build-id is not present in the core file, GDB will return None for > Andrew> the build-id. > > Andrew> Of these two I suspect the second; for a period of time the GNU linker > Andrew> was ... changed ... such that it no longer placed the build-id within > Andrew> the first page of a generated ELF, as a result, the Linux kernel would > Andrew> not include the build-id in core dumps. > > Andrew> We can check for the second case using: > > Andrew> readelf -WS /lib64/libc.so.6 | grep build-id > > Andrew> The output will be something like: > > Andrew> [ 2] .note.gnu.build-id NOTE 0000000000000370 000370 000024 00 A 0 0 4 > > Andrew> It's the '000370' column we're interested in. If this value is greater > Andrew> than a page size, then GDB isn't going to be able to find the build-id. > > I have a question about this work. > > There's an internal AdaCore test that creates a core file, then uses > 'file' on a different executable and 'core' to check if a warning is > issued. > > gdb 16 on this test does: > > (gdb) core core > warning: core file may not match specified executable file. > [...] > > However with git master we don't get that. > > Now, the executables in question do have build ids: > > bapiya. readelf -WS call_crash|grep build-id > [ 2] .note.gnu.build-id NOTE 0000000000000390 000390 000024 00 A 0 0 4 > bapiya. readelf -WS crash|grep build-id > [ 2] .note.gnu.build-id NOTE 0000000000000390 000390 000024 00 A 0 0 4 > > ... and I verified the the IDs are actually different. > > I'm not really sure how to find the relevant page size, per your comment > above. > > I can't readily tell if the core file has an ID. gdb thinks there > isn't, using the command from py-corefile.py. > > That by itself seems a little weird but I am wondering if the warning > should appear anyway, at least in this case, because the core file > records it was created by 'crash' but the current file has a different > base name ("call_crash"). > > IOW, is the lack of a warning in this case now intentional? No this is not intentional, and I can reproduce this. But I thought we had a test that covered this specific case already, so I'm really surprised this wasn't flagged during testing. I'll investigate what's going on here, I guess I've managed to break something.... > > And, how can I understand why the ID isn't in the core? > I'm having some trouble figuring out which 'ld' the compiler is invoking. The offsets of those build-ids looks fine (less than 0x1000) so should be within the first page of the ELF. This will be something I've managed to break somehow :( Sorry about that. Thanks, Andrew