From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id fSrYDCLsm2oway0AWB0awg (envelope-from ) for ; Sat, 05 Sep 2026 06:17:06 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=fOi6ICT8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D88751E09E; Sat, 05 Sep 2026 06:17:05 -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,FREEMAIL_FROM,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 vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 596AF1E091 for ; Sat, 05 Sep 2026 06:17:03 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D4AA4BB5923 for ; Sat, 5 Sep 2026 10:17:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D4AA4BB5923 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=fOi6ICT8 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id C553D4BB5905 for ; Sat, 5 Sep 2026 10:16:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C553D4BB5905 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C553D4BB5905 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::332 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788603399; cv=none; b=m6scFYm1MUBNgxGQ73I0EUftiKMMlyRZ97U2rTNeyaPzLsJtqYqbdnFqRlWeLqNdJVzYZQWeTscleOQrSKJbyPf1tBKu7Al9i5xpoYdU6u0ZTPESzTysaGRzDLKTfKZph7DMWiZIq/K5OuwWt90xIYG31zHOuiTwuri/kFk+KPU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788603399; c=relaxed/simple; bh=+m0JjNhqn9w2hd+96rD5ID04sIdMyaYEOUS1YtjJUiw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=qTnXWmxn4mR8H4vdoXawWN+SO4BmdYEuhL0bAn0P7RtYr2dVOj0f1crSQBkl1Pcexr+Tpt79fnH/RDG4hLOREJAt6Xom72rsz4iZVMDySOvcTF+LS64lCZbslYxnyx7HeVj8BmC4bzImS7B7Ms5R1CYZFgbWQ9L5UBKpBJiduXU= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=fOi6ICT8 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C553D4BB5905 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso16299015e9.3 for ; Sat, 05 Sep 2026 03:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788603397; x=1789208197; darn=sourceware.org; h=content-transfer-encoding:content-type:subject:from:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=HHASype61J7FlnHQoFO23xeIs6sGhrFMBzMKPfqzDL8=; b=fOi6ICT8b9+dnwPz5bfKYZLGb8g6WPkwSAxlvLEKTZmpozRaZ68Own09vVqAaoc6so 57w2ED5CRpe5OAmvfS03mIp/inP0z0wsAs/22HtzEalsDCHNvK94TQ/uAXE/M4ai1EjP IYhdTSlhaB97gzF6uzIPHCTuDCT3fF9DZBNf9OPBBzrvTVGQ6bHfOT1HQSLLdgcgmal0 Zl9wwVZ9yn0iuDuaVKDKLQNHOAhMccl0YrdoI41XEdc3SlVw+PfQRtah2Q1nCk/bv9ZA fPbB+e7LZT4TsAYFXDKfBIbrQyropqUXeNl0AN6g3bkl+2feYbGyWcdNHug5Og8iR5ky wFkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788603397; x=1789208197; h=content-transfer-encoding:content-type:subject:from:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HHASype61J7FlnHQoFO23xeIs6sGhrFMBzMKPfqzDL8=; b=EJYzhNBqkkiSWhotJhj6YLgI5bZP0BqQwX3UmkaRiwFqltI3c+IycoEes35ltSCTHe XhXwmDbPrwH7danrtLQCOSaGi0/gRQzIEU+rBZE7q7J7kk9Uy+9cPm7Trj/HJ7mzcPr5 7ec1l0YBEZlv7mXzHibsecOZwYT6PuRM/UQhHmsIri+ZBwX/aTqOT0P78XaIF+4v5Z18 sQn+ylHxhJ5bSnSFnYaZ5iLDwFFLVp9WBJ36am6ibEQMv/G3hZ3DD1+jJ1vTMQct73cf ySLpKqWJ3UnVyBr+j9jTmuuzUW/ta9nctkmtQzhlZO39n3AoAuYWItpkowLGvJ1D6h3R wOyw== X-Gm-Message-State: AFuF++nINmdJ/6cdO3fI85yWkOqVK9yJlfEdRWgczTH9C7PkL/YgRnZ6 Rk7URIp+BA932K8+UcJzNhxAJ7e4Bd4MWkfyGNjX7RpI0mLvt3PV9enYRzVM X-Gm-Gg: AYBFou3W7loQZDqI+vKiULGhsIXXWsdDfY1ApiVVtfgf1gTs3G5ne/50zgnFgm054g1 F06YtsQKmUXxtho4u2d1TN/MUHideaI4bH7yU/z77VyCJ4qeMDn4uX8XDC2apAwjJE28gPRqe8X XDOadQj435Z+UPuw80TQMkHXdAkvF5WE/2mAdsAAlNUBj0mYQ2qN6uokuNnffjEvDFJAUZOQfkv EiHV0pyPB6UsVjuhPbxunZDTx41AZHJ7q9E8ldUfJDGo6rblTEjFZTj6b+A/PJfqQC04kqwaVRa KLC74/2yFgxan7UTzgHGyBOQ6KKReNnve4EMopOhy4i7hxYQcgxW3TR3pG4pPJZqUq6VBOY2b/+ wXMk/svtSXEsYJIx+HTQ16BDVEzTpSYdgQTc6atdBr+GuuWMNF1l87XlLTYA4Z3/WvtqeEYRqwQ VWwRjJ/XTQO5+55wIpXhtvysvrZOuq82x4TR05jX32MLYxysUZI2M0E3IADNkYJXv/pwsEMY7oG VBnOrWyNwrZolSOIYtBz0n1bJVOTOSmBgLF3ooJVJp2yrPsoqZOSV5kkqyJmQwlVLoo0ohXzZ5q AtBE4JMm5PA+naIR4+OPsQ9JNCWMK2qk9yg= X-Received: by 2002:a05:600c:3b07:b0:49c:fa20:cbfb with SMTP id 5b1f17b1804b1-49cfa20cd04mr97006765e9.18.1788603397357; Sat, 05 Sep 2026 03:16:37 -0700 (PDT) Received: from ?IPV6:2a01:cb0c:8b36:7600:ab61:2c55:c20a:8252? (2a01cb0c8b367600ab612c55c20a8252.ipv6.abo.wanadoo.fr. [2a01:cb0c:8b36:7600:ab61:2c55:c20a:8252]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf7703cc7sm140888325e9.4.2026.09.05.03.16.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Sep 2026 03:16:37 -0700 (PDT) Message-ID: Date: Sat, 5 Sep 2026 12:16:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: gdb-patches@sourceware.org From: Dragorn421 Subject: Fix `add-symbol-file -o ... -s ...` address mapping bug Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 Hello, I encountered an issue in GDB and am hereby submitting a patch for fixing it. First, let me explain the problem: it has to do with the `add-symbol-file` command that is used to map elf files to arbitrary addresses. For example if I want to map the .text section from main.o at 0x1234: ``` (gdb) add-symbol-file main.o -s .text 0x1234 add symbol table from file "main.o" at         .text_addr = 0x1234 (y or n) y Reading symbols from main.o... (No debugging symbols found in main.o) (gdb) info files ...         0x0000000000001030 - 0x0000000000001040 is .plt.got         0x0000000000001234 - 0x000000000000132c is .text         0x0000000000001138 - 0x0000000000001145 is .fini ... ``` `info files` does then report the expect address for .text However this breaks when combining with the -o "set offset for other unspecified sections" option: ``` (gdb) add-symbol-file main.o -o 0xFF000000 -s .text 0x1234 add symbol table from file "main.o" at         .text_addr = 0x1234 with other sections offset by 0xff000000 (y or n) y Reading symbols from main.o... (No debugging symbols found in main.o) (gdb) info files ...         0x00000000ff001030 - 0x00000000ff001040 is .plt.got         0x0000000000001040 - 0x0000000000001138 is .text         0x00000000ff001138 - 0x00000000ff001145 is .fini ... ``` We notice here the -o option was correctly used per the addresses of e.g. the `.fini` section, but the .text section address is now wrong. This behavior boils down to the `set_objfile_default_section_offset` function assuming it can pass 0 as `objfile_relocate`'s `offsets` entries to not modify the `-s` mappings previously set by the `symbol_file_add` call in `add_symbol_file_command`. When in fact `objfile_relocate` does not check for 0, it only checks for the new offset being the same as the current one. The proposed fix is to change `set_objfile_default_section_offset` to pass the current offset instead of 0 for sections that should be unaltered: ```diff diff --git a/gdb/symfile.c b/gdb/symfile.c index 017f7a49d8d..5691c2a46d9 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -2139,8 +2139,8 @@ set_objfile_default_section_offset (struct objfile *objf,      = addrs_section_sort (objf_addrs);    /* Walk the BFD section list, and if a matching section is found in -     ADDRS_SORTED_LIST, set its offset to zero to keep its address -     unchanged. +     ADDRS_SORTED_LIST, set its offset to its current offset to keep +     its address unchanged.       Note that both lists may contain multiple sections with the same       name, and then the sections from ADDRS are matched in BFD order @@ -2163,7 +2163,7 @@ set_objfile_default_section_offset (struct objfile *objf,         }        if (cmp == 0) -       offsets[objf_sect->sectindex] = 0; +       offsets[objf_sect->sectindex] = objf->section_offsets[objf_sect->sectindex];      }    /* Apply the new section offsets.  */ ``` This is my first time contributing so my apologies if I'm doing anything not properly, please let me know. Sincerely, Dragorn421