From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HhIeB4OJsWr6dS4AWB0awg (envelope-from ) for ; Mon, 21 Sep 2026 15:46:11 -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=ime+M0n5; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 05E311E051; Mon, 21 Sep 2026 15:46:11 -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 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 E97EB1E01F for ; Mon, 21 Sep 2026 15:46:09 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7505C4BA7992 for ; Mon, 21 Sep 2026 19:46:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7505C4BA7992 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=ime+M0n5 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 297D04BA2E11 for ; Mon, 21 Sep 2026 19:45:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 297D04BA2E11 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 297D04BA2E11 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790019943; cv=none; b=Pk9fwcAY+qXKYaAeMTRkv51vhydXTlh4P+an+ujz5TeDR9lpPFUxxtYMi9/K82vJwiq/PEtiJGcqpF9Qh3FjdjRm7ekzr5kkd99B2wMoDPyss3xpDQq6E8qp4ABYywu3uoZhOfcAJaguBBkJXE7+DsPvyyumA38whCzjN6cZAA8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790019943; c=relaxed/simple; bh=zezIisqcpNa+hYQtl6r9rSwpvXTpLFmKAOByKxoJoPc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=KZ0auQVX6haiFWgSReXPk7liMSrnWd+JMgXlXAlQx0DdtIl1ipuviC2q4qCNyCaKJ0IwXCFL9SkQ6D1Gi11m5wosSCxPZkSVsr0gjznU7dpEixJDZblZn67RAMcOG3iWQYMrd3PBizhLREEJm+AFt2Jff0bugXsra9WUM29nLI4= ARC-Authentication-Results: i=1; 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=ime+M0n5 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 297D04BA2E11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790019942; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=duKZtEqiNcMS4WCE1959WRqSira9sYO33tp3y209rys=; b=ime+M0n5HhnvOe0v5/kFNOMpb62X65A6VmraZzKu4ervYhFWtBJ7qbBu0eMPkckdHgT5a7 yOYbhCC45FSwIUAhd2FPPm5hfJ+u9Q67uxA8KgvSsBerTFD3avbVxg7gt92N8x0PS5u1Un btme+X0MnOtOSmQ6rthTWgXqdSNrlYA= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-79-jDObnVG6Oxq_Q9iZ696gLQ-1; Mon, 21 Sep 2026 15:45:41 -0400 X-MC-Unique: jDObnVG6Oxq_Q9iZ696gLQ-1 X-Mimecast-MFC-AGG-ID: jDObnVG6Oxq_Q9iZ696gLQ_1790019941 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-912348a0ffbso37218806d6.3 for ; Mon, 21 Sep 2026 12:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790019941; x=1790624741; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject: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=duKZtEqiNcMS4WCE1959WRqSira9sYO33tp3y209rys=; b=QG9m2fq+9CPJpBUO5QemMYK5Nrq3yBV20tsYjGmCz72xI69pjyUeftBYlkKWf7MhD2 pifvuysp8oAmSsNcQZwsSMORkBtE059AzR5lIo6jBwwYGB4LKDATp7CAAws6269eY+Tp KB8EoXJS90h9jOtHje5r6/twYg1Vzd6SbIbuaf4MSMTjsmuBIoKvJTQ/V2GmmG6eEn6Y QinDwQuqMnbS0oelIctGADaeWdZPOyF/hStVtrhhYqurUXs3uqAkLUA5wSF+CFj/IKKF jP+mqN0PcGWa12a5uBS8s5oH19GqHBqOyzFI/iY9FwrZNs1Ed8woV0a/MSlC0JRYGNMX Zw0w== X-Forwarded-Encrypted: i=1; AKwUvBwNoJfC3925+csm6fKnqJ7wgGH2w2X2f2eBaJ+Z30MIssFjG4ecUVsbMiO1qdUF4k/8FCNmO/JfCv0cyg==@sourceware.org X-Gm-Message-State: AFuF++macFrt8ot4aeB31jjAEKDGd25lCqDUiU3hUbU9kUTucvWulbTb Wh0W9sLdl612J5cKzJZAOOwUm59oFyopsctHflYLoYK0p3Ci3+6WyeGncSEt1ZZPPVsxdL7FomN bUlmnogzsoULv3KulFw6nfT8+HPW5rAPtMPit7caAth8u7aDTIPqwW6hWYNkHgpM= X-Gm-Gg: AYBFou1GJKG5J9SW1D4TlFOzw94dfeWATetxEO7SygV177+sO4oP+Rek48pbSLtPsfy QOVXi9cWrMEcVYLqwoQqvwvCwsj3onN4447/JXIP0XvG4GssLo3Hhg/r/i6vZS2GPetBQnYdnJD BOxBWGnkWdvPbYS3TpY/czcwm5In+OcfmCWjX/OAhs57fqQTr207B+2dY54SkIyRWlPDLZRdy19 Hkfb5YdGw4C35tSSJk3q/4dgAXAqYzVw59+5AL55q97KyP07bBwEcVoWL2XHrdbcXspppDsIjf4 dudMPyTN22B2/zHGAT8zndkh/uHAxAfZCCEQpo4pGhnDw99OYHP4Urd2cFJSXXJe92vMihpxCW9 dxDIo7KE= X-Received: by 2002:a05:6214:4104:b0:912:517b:7be1 with SMTP id 6a1803df08f44-913fc9b0db8mr22753816d6.44.1790019940880; Mon, 21 Sep 2026 12:45:40 -0700 (PDT) X-Received: by 2002:a05:6214:4104:b0:912:517b:7be1 with SMTP id 6a1803df08f44-913fc9b0db8mr22753456d6.44.1790019940396; Mon, 21 Sep 2026 12:45:40 -0700 (PDT) Received: from [150.1.200.157] ([172.56.108.234]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91260aa20e4sm75206816d6.40.2026.09.21.12.45.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 12:45:40 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 12:45:38 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PING] Fix `add-symbol-file -o ... -s ...` address mapping bug To: Dragorn421 , gdb-patches@sourceware.org References: <91e0ae19-bbde-4235-9cea-335127512ede@gmail.com> From: Keith Seitz In-Reply-To: <91e0ae19-bbde-4235-9cea-335127512ede@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EoAUo6YsTdwlZy6PuUNeYc_SM4QH1Dgpfmrue8cH0K0_1790019941 X-Mimecast-Originator: redhat.com Content-Language: en-US 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 Hi, Thank you for submitting a patch and fixing a bug! It is very appreciated. Overall, your patch looks good! I just have a few (very) minor comments to clean it up a little. On 9/20/26 7:02 PM, Dragorn421 wrote: > ---------- Forwarded message ---------> De : Dragorn421 > Date: sam. 5 sept. 2026 à 12:16 > Subject: Fix `add-symbol-file -o ... -s ...` address mapping bug > To: > > > Hello, > > I encountered an issue in GDB and am hereby submitting a patch for > fixing it. In gdb land, we typically submit patches ready to commit. That is, we use "git send-email" to send patches to the list which, once approved, can be applied directly to the tree. You've started well here: you're subject line is perfect. [I don't know if you have any interest in submitting future patches to gdb -- I hope you do! If you don't, just ignore me. :-)] Now let's fix-up your body text a little: > > 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. I simply recommend changing this slightly to read: 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. Those two options are currently may not be supplied together in the same command invocation. [then keep all the below] > 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: And there you go! Perfect commit log! The only real additional ask, per the contributions checklist[1], would be a test case for this to make sure this never regresses. Are you able to do that? You could modify or "copy" gdb.base/relocate.exp to exercise this specific use case. [1] https://www.sourceware.org/gdb/wiki/ContributionChecklist > ```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. Your fix looks good to me. If you'd like to "address" my review comments and submit a v2, please do! Otherwise, we'll have to await final say by an approving maintainer. Reviewed-By: Keith Seitz Thank you! Keith