From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id A4UnLjw0smowvjEAWB0awg (envelope-from ) for ; Tue, 22 Sep 2026 03:54:36 -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=aaZhQdfg; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9EECB1E06B; Tue, 22 Sep 2026 03:54:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 9EA971E033 for ; Tue, 22 Sep 2026 03:54:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A0A164BAE7CF for ; Tue, 22 Sep 2026 07:54:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A0A164BAE7CF 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=aaZhQdfg Received: from mail-wm2-x10.google.com (mail-wm2-x10.google.com [IPv6:2a00:1450:4864:31::10]) by sourceware.org (Postfix) with ESMTPS id F082F4BAE7CE for ; Tue, 22 Sep 2026 07:54:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F082F4BAE7CE 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 F082F4BAE7CE Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:31::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790063650; cv=none; b=twAlWsr1+SUzW7IATba0z4FA1YfAMlVf4IfARy/yzkimDufIRT9SzTVAQF3nBCsm5a3ydQNDq5qdNYDje8hH5UjK9lxv5f6rcAH5ajH2szjs3SUFBPsYRBiEMbVD1/Z7yBJ39CQGjie2ZOJW9oBQqaXwTEAMQUQ9rosKHNfCzI0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790063650; c=relaxed/simple; bh=mRPObnxzrz3rBxW9iP7WnjNSkyrP64AF/hH7B+z1PQs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dyBfTK9gPIHwTJKfbQRKJhOy9gBWJKiCcAJPswLRoR+S9GLrewtsr56MyIrG2EjS/DFd3mWwOvCFX3BEeNaThAHBWbWEVUUJYOpeEMtbQNAWDn1McNeQ/y29y1t2ZL/kcMY4vsDSR/ZW4f0JIG7FLmdI4rcF5ijKEbHFbQD7La4= 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=aaZhQdfg DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F082F4BAE7CE Received: by mail-wm2-x10.google.com with SMTP id 5b1f17b1804b1-49b912e4b11so20492935e9.3 for ; Tue, 22 Sep 2026 00:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790063649; x=1790668449; darn=sourceware.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=CWVJVH3p2YQ9eQ64G0inBOYMpVTqaBNFAxAugmfxqgs=; b=aaZhQdfgprQzalBwNTzfeT+rLopsTEuB/jkPPpWTc39J0PXiejuIjiFTaek4pgtMFy gNH4Lmkd3RYKGJk954+O00QL2t5Ywa806JgO3TEBmrgKs85DDvDNFTiRuvYnPWG35Rsj jHfIkl/SmdGQRg54+T9r2r86r+21L4NaTwImaMXHdMoHDVOJyA3o0BSGnkTYhgPXHpaa A6XIYOz7BTjy4NhSkl4FhWEoYzqNlLgcod/NP0RBSkCkTS/Lw4jLq9UX7bTU1qpZt2TK 3qUud7fmmIypoH/bRrOu/E3CJlSI/lYu2EudTUqbmIKAF9IUhOWqF8hACET/1jKkOoMo h/RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790063649; x=1790668449; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=CWVJVH3p2YQ9eQ64G0inBOYMpVTqaBNFAxAugmfxqgs=; b=VBKVC/h1cXPh2oJMBD1KOaB55xLWfujdle5JhqmtzMPHw0XIaO08TEh+JNcV+35X0G JpJU9AmpJQV/AEtB2E0AXw3ZWpi6KZuPmyJTDKvINIHAXW1KFtkQ5ChMSXvMW9NYVNgj 8GDc7f/sCFK6rAv2wnBsHP95v/KMPtj0nbbMU/CdIJ64L28+o9GCe1Q14pLGchHphMjT MZDYsUixbWFzRfrR0f0xdqZJtbGGOcLg1JpWKp6BSMEnEIDY/JcLpSbqddoqzp6ZNKo4 KPCfXSmaNNO8w4uVIF7Usj6akWX/n8k8JtvqQfMb/KL0jPa+6g1rXdrYosZop+qeVqnS ytsQ== X-Gm-Message-State: AFuF++kD6bOUircqPiu+OEztHgZycdf1KxpMWoTSCPFWtlsPNOnfHgBW XQmcOIoPFknlMQXycBc66y4Mf+GThVQAHlaq5mRm2HumwzhPjnRUN6uSDAgffH0= X-Gm-Gg: AYBFou1tlRz3RAfKg8/PDlYN5qoR4dh5UwjdZ469h4LdtMnJ0PIcWI8gUgagd5rL+f/ pRnDT/9tEtqOEqMlJ0NVL9IIiypFt4ibKs11BcNBF0e3jmwebnVM9WRmgoTae22+6XsOGHZLzVn UaQwsISpGcWueA99jJsNwbY0rEHgRomI6P6x31XgWMPKqKir5oYRq2WMkEWX7NgOKBBtCuCbp1I PH7L2sF2+pzX3NWF+vXQ43k2C7EpO2y2iTYsoDWVHVUfHDTAYjW3pfu+xR2FpRNX0qYPS+Ssxg3 Im536Zvj7+pvXKHILKjc3WciMKTTSTZTZRBkK5ZhdcsH/B/crq8/e4uDbAOJ1ZQMtG3HsAYXq4q 4kCOebkQWadHX1iHPFSk9FSiNAEYjadAXGU62NjdZropsZCqJmSe08Nzx97Yc7/3xMbruvU5KqP HX17l5/XNoJn+nCKuAqQZsl8jdPqKNSSjvlT7waCvcapPlTdK2iV5rFy8omjtPQzeCuA60AUDKt hDHpSW9c+JFgDZZek/tRXhqBTPnq3QKTSs9gtn54hUo9gijRUJZMFeSslOsjBJmPhhTCIEq X-Received: by 2002:a05:600c:19d1:b0:49c:fc6e:a3d6 with SMTP id 5b1f17b1804b1-49fc574ef3cmr165438005e9.21.1790063648505; Tue, 22 Sep 2026 00:54:08 -0700 (PDT) Received: from dragorn421pc.home (2a01cb0c8b36760068aa4f15600854a7.ipv6.abo.wanadoo.fr. [2a01:cb0c:8b36:7600:68aa:4f15:6008:54a7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fd8cc05e9sm54554125e9.5.2026.09.22.00.54.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2026 00:54:08 -0700 (PDT) From: Dragorn421 To: gdb-patches@sourceware.org Cc: Dragorn421 Subject: [PATCH v2 1/2] Fix `add-symbol-file -o ... -s ...` address mapping bug Date: Tue, 22 Sep 2026 09:52:43 +0200 Message-ID: <20260922075252.104346-3-dragorn421@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260922075252.104346-2-dragorn421@gmail.com> References: <20260922075252.104346-2-dragorn421@gmail.com> MIME-Version: 1.0 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 The 'add-symbol-file' command allows users to map sections explicitly ("-s SECTION ADDR") and apply an offset ("-o OFFSET"). The documentation explains: If an optional @var{offset} is specified, it is added to the start address of each section, except those for which the address was specified explicitly. But those two options currently may not be supplied together in the same command invocation without encountering buggy behavior. For example if mapping 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 fix is to change `set_objfile_default_section_offset` to pass the current offset instead of 0 for sections that should be unaltered. --- gdb/symfile.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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. */ -- 2.43.0