Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Dragorn421 <dragorn421@gmail.com>
To: gdb-patches@sourceware.org
Cc: Dragorn421 <dragorn421@gmail.com>
Subject: [PATCH v2 1/2] Fix `add-symbol-file -o ... -s ...` address mapping bug
Date: Tue, 22 Sep 2026 09:52:43 +0200	[thread overview]
Message-ID: <20260922075252.104346-3-dragorn421@gmail.com> (raw)
In-Reply-To: <20260922075252.104346-2-dragorn421@gmail.com>

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


  reply	other threads:[~2026-09-22  7:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22  7:52 [PATCH v2 0/2] " Dragorn421
2026-09-22  7:52 ` Dragorn421 [this message]
2026-09-22  7:52 ` [PATCH v2 2/2] Add test for mixing -o and -s Dragorn421

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260922075252.104346-3-dragorn421@gmail.com \
    --to=dragorn421@gmail.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox