From: Martin Simmons <qqxnjvamvxwx@dyxyl.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v2][PR symtab/32658] Fix parsing .debug_aranges section for MIPS signed addresses
Date: Thu, 27 Mar 2025 16:03:45 +0000 [thread overview]
Message-ID: <jea59631ge.fsf@localhost> (raw)
In-Reply-To: <87tt7pj7au.fsf@tromey.com> (message from Tom Tromey on Wed, 19 Mar 2025 10:48:09 -0600)
>>>>> On Wed, 19 Mar 2025 10:48:09 -0600, Tom Tromey said:
>
>>>>> "Martin" == Martin Simmons <qqxnjvamvxwx@dyxyl.com> writes:
>
> Martin> This patch fixes https://sourceware.org/bugzilla/show_bug.cgi?id=32658 by sign
>
> There should be a 'Bug: ...' trailer in the comment with this link.
>
> FWIW I see now that other spots in the DWARF reader do use the BFD
> approach:
>
> int signed_addr_p = bfd_get_sign_extend_vma (objfile->obfd.get ());
>
> Martin> I made it explicitly sign extend the addresses after they are read
> Martin> (instead of using extract_signed_integer) because I don't know if the
> Martin> address_size in the section will always be equal to the gdb arch_size.
>
> I don't think this should be a concern, unless you have an example where
> it actually happens.
>
> The .debug_aranges header spec explicitly says "size of an address in
> bytes on the target architecture".
I've not found an example (and both gcc and clang explicitly write them
using the target's pointer size).
Here is v2 of the patch addressing the above.
Fix parsing .debug_aranges section for signed addresses.
Some architectures, such as MIPS, have signed addresses and this changes
read_addrmap_from_aranges to record them as signed when required.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32658
diff --git a/gdb/dwarf2/aranges.c b/gdb/dwarf2/aranges.c
index 7016eee557c..ac530abd6b3 100644
--- a/gdb/dwarf2/aranges.c
+++ b/gdb/dwarf2/aranges.c
@@ -59,6 +59,7 @@ read_addrmap_from_aranges (dwarf2_per_objfile *per_objfile,
gdb::unordered_set<sect_offset> debug_info_offset_seen;
const bfd_endian dwarf5_byte_order = gdbarch_byte_order (gdbarch);
+ const int signed_addr_p = bfd_get_sign_extend_vma (abfd);
const gdb_byte *addr = section->buffer;
while (addr < section->buffer + section->size)
{
@@ -167,8 +168,13 @@ read_addrmap_from_aranges (dwarf2_per_objfile *per_objfile,
plongest (entry_addr - section->buffer));
return false;
}
- ULONGEST start = extract_unsigned_integer (addr, address_size,
- dwarf5_byte_order);
+ ULONGEST start;
+ if (signed_addr_p)
+ start = extract_signed_integer (addr, address_size,
+ dwarf5_byte_order);
+ else
+ start = extract_unsigned_integer (addr, address_size,
+ dwarf5_byte_order);
addr += address_size;
ULONGEST length = extract_unsigned_integer (addr, address_size,
dwarf5_byte_order);
next prev parent reply other threads:[~2025-03-27 16:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 23:57 [PATCH][PR " Martin Simmons
2025-03-08 16:39 ` Tom Tromey
2025-03-09 20:40 ` {Spam?} " Martin Simmons
2025-03-19 16:42 ` Tom Tromey
2025-03-19 16:48 ` Tom Tromey
2025-03-27 16:03 ` Martin Simmons [this message]
2025-04-03 15:03 ` [PATCH v2][PR " Tom Tromey
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=jea59631ge.fsf@localhost \
--to=qqxnjvamvxwx@dyxyl.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