From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GTQ9D5+etGqjxToAWB0awg (envelope-from ) for ; Wed, 23 Sep 2026 23:53:03 -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=qy9MBKpg; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 028E21E033; Wed, 23 Sep 2026 23:53:02 -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 1C4D21E033 for ; Wed, 23 Sep 2026 23:53:01 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F7414BB3BE4 for ; Thu, 24 Sep 2026 03:52:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F7414BB3BE4 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=qy9MBKpg 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 4CC314BB3BD8 for ; Thu, 24 Sep 2026 03:52:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CC314BB3BD8 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 4CC314BB3BD8 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=1790221953; cv=none; b=l07c0cEun+gsBt0cb6henlac8KBehBr59P5XqgJBrs3pHOx169+OaQV5vn+i0Ndir80FD1JmFuFGZ1QeU11ilztz6/sik/UVe5R5wGKBx1MLqD9rv+2reZzhQo+XbUvt2Hap89wIs+hyMPeUOf8Jz1qYjTzJkkGw+sLASTk5zms= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790221953; c=relaxed/simple; bh=mRPObnxzrz3rBxW9iP7WnjNSkyrP64AF/hH7B+z1PQs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=d6R7Z36NcmXfTlu9eHE8dcVCm8WLo0gZDJVSbW/ngJetx3sEGmzDqaEJKw0jx4aLuRq+LLyHIJF+1fEwFUdaeWOKVFKiU6TWfvCetztWFsMqkoPZ0ALA1qXVLVuHrgeoIzOm34QpnjKi7KqLmvXiixCUDIQnR/Sa8YdATb1ucwQ= 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=qy9MBKpg DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4CC314BB3BD8 Received: by mail-wm2-x10.google.com with SMTP id 5b1f17b1804b1-49b912d391aso11295085e9.2 for ; Wed, 23 Sep 2026 20:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790221952; x=1790826752; 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=qy9MBKpg6aMiPXH7D0QJhh/fyc7UJJ9n1eiKVPbZv2PDOHJ8bGFDLUiY5Vn55GswR8 8vt8XW8pm0SzomC4q8zupFAQoWSeFgiPB14mtnnHuE/PTzf79Zbt3r3WQb98jDQXsghP PxPNnY3rxpO0Pxd+TRpPuqByrV1z9+Ik+8LIfyBv0/XqbiFPwCW03zNVHaT3dG2bTDvp xIFf7MnDvoEVReBuKxD1wZu//idBUFEUW9mkhoWRKOnld7l1NRhejRWwh6hQUu03BCLO 5h5RNM6vWvJJ8g2soMXJZ58I5hUYBGwbSarnSllrixVCBopsyhD+qDa02kE+kriRnWIh KJNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790221952; x=1790826752; 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=pDDnQR167JWzD2QkHiyFuaEI071JcsMt8iUs+17DzOQZ4QiTZ8hco4KSz1ccv9ZlJi VRUJj0ei/+/WM3R7NxDh5EAKzSRT4O0E78GnHHLDhjUtuvcJIb6B+m8dQXb9gHt+q0xt Ew2xlRvhWojxWiDpTBnWpKpFrO+AGUcHVF078xLHs8TshirkxIEB85XcRSdnsVH0Azqr gz2t88cCg1T9kbfs5T5MnHX9FgovOwoctjeJmZ0m+3Ql3hBIerrTK6L+KkBxjdHj6nfi vC2a93lv+WfS6lUgSR/qjIBfJx/XwHm01C0H/ThTme9DS79ilTzlrP915vOpHxAvpJCS 0OUA== X-Gm-Message-State: AFuF++knRwXdWQO39HJrmOrgEe8/JFbJ9U72tk0QwyewjtaBhXf/KZs6 HIHjWGA5r6mFjTbfUyriqiLIc8GsHnnI87uFpsZYvT4QMcty0vEdMr5L1uZNzU8= X-Gm-Gg: AYBFou3auG+ZkuuKs8tqVc18+S7Ikq1syAm8CH9mOzl06z/Ys+gBYHrcfRbZF3bS5lY z7dFGt/hmrFV9ZPhj9DBcrFDsafu39miWSZccZMUtOk19oxK4vQnIkLPXQdqPkyzxafGfaXezyZ FQQa9QlAnkFwlgwazOg9rDJ1IS6X+FAwD0jtGU/v9yD6BhDk7cFDo5tCYlRqSTSRfJTFPXXbSJ7 uwBmVlzEJ3LQT5R2z96HSDkWK7xtroUBwYd58rTfu6slQ4Pmj1ks20nsiIquvl+uAyYyV/XBZ76 xjW2lYXLUbLj2WQrIVMXU6f+5b2SpR8WXI6ZYDdGKy8eHM9WlWO3hnXkKcwFA3vRQHQwpfvPFcv aSoN5VvuOxah8lBbWTAlgBSlvOfkbjOibDtfNuOPcB2P+qfdeYJZCEt/Uw16qLbHku95SYC60dq m4vdCwZTcvkJ6keN7VPHrGWD6pUiHQS+YgL2XqPB/YCERr6135ChHvKrGFTm3HAct8GqyMELytJ O4l0elfPVpH5TZ9Dg5yHtsmTRIN9hXactVcdM3MzvOykVOiP1mlNghobItyOczpk3/V1/Q= X-Received: by 2002:a05:600c:4ed2:b0:49f:e3f2:f5a3 with SMTP id 5b1f17b1804b1-49fe6685393mr19034845e9.0.1790221951913; Wed, 23 Sep 2026 20:52:31 -0700 (PDT) Received: from dragorn421pc.home (2a01cb0c8b36760075f631915ba675a2.ipv6.abo.wanadoo.fr. [2a01:cb0c:8b36:7600:75f6:3191:5ba6:75a2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c5c41asm81524955e9.4.2026.09.23.20.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 20:52:31 -0700 (PDT) From: Dragorn421 To: gdb-patches@sourceware.org Cc: Dragorn421 Subject: [PATCH v3 1/2] Fix `add-symbol-file -o ... -s ...` address mapping bug Date: Thu, 24 Sep 2026 05:51:25 +0200 Message-ID: <20260924035202.4533-2-dragorn421@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260924035202.4533-1-dragorn421@gmail.com> References: <20260924035202.4533-1-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