From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/dwarf: fix reading DW_FORM_addrx with address size of 2
Date: Mon, 21 Sep 2026 10:41:16 -0400 [thread overview]
Message-ID: <af0e0cb7-b012-4e78-b567-c232eca8222d@polymtl.ca> (raw)
In-Reply-To: <87eceqv5to.fsf@tromey.com>
On 9/18/26 1:15 PM, Tom Tromey wrote:
>>>>>> simon marchi <simon.marchi@polymtl.ca> writes:
>
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> While investigating AVR binaries for bug 34638, I stumbled on a crash of
>> GDB when loading an AVR binary generated by clang:
>
> Thanks.
>
>> + /* Check that the whole entry fits inside the section. */
>> + if (addr_base_or_zero + (addr_index + 1) * (ULONGEST) addr_size
>> + > per_bfd->addr.size)
>
> The cast to ULONGEST seems weird to me, especially since it isn't
> repeated later:
It came from Claude flagging this in my change:
(addr_index + 1) * addr_size
This is computed as unsigned int, which, in the (unlikely) case that we
would deal with a .debug_addr section > 4GB, would get the offset wrong.
>> + const gdb_byte *info_ptr
>> + = per_bfd->addr.buffer + addr_base_or_zero + addr_index * addr_size;
And you're right that the same problem exists here.
While re-reviewing, it also flagged that DW_AT_addr_base could have
absurdly big values, and the add could overflow 64 bit, which could also
lead to an out of bounds read. A safer way to do this would be to
subtract instead of adding to do the bounds check. I'll send a new
version for that.
I also renamed info_ptr -> addr_ptr, I'm pretty sure that "info_ptr"
that we see everywhere comes from pointing into section `.debug_info`,
which is not the case here.
Finally, when I asked it to re-review, it flagged that the testsuite
changes to add DWARF 5 DW_FORM_addrx/DW_AT_addr_base support were not
correct. In the DWARF 4 GNU extensions (DW_FORM_GNU_addr_index /
DW_AT_GNU_addr_base), the .debug_addr section has no header, it's just a
bare array of addresses. But in DWARF 5, each contribution has a
header. GDB doesn't read that header (it doesn't seem useful to do
so), so it didn't cause a problem in my test, but to make the DWARF
assembler emit a valid DWARF 5 section, I'll change it to emit the
header. Otherwise, you can't even dump the section with readelf:
$ readelf --debug-dump=addr testsuite/outputs/gdb.dwarf2/dw2-addr-size-2/dw2-addr-size-2
Contents of the .debug_addr section:
For compilation unit at offset 0xc:
Index Address
readelf: Warning: Corrupt .debug_addr section: expecting header size of 8 or 16, but found 0 instead
Simon
prev parent reply other threads:[~2026-09-21 14:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 1:45 simon.marchi
2026-09-18 17:15 ` Tom Tromey
2026-09-21 14:41 ` Simon Marchi [this message]
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=af0e0cb7-b012-4e78-b567-c232eca8222d@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/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