Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

      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