From: Can Acar <canacar@imcan.dev>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix: Sign extensions for DW_FORM_addrx were never considered
Date: Thu, 23 Oct 2025 14:44:46 -0700 [thread overview]
Message-ID: <CAKB9nm+W+4ZGR_Ahf6j3GEOUm6Qv+k-O--CLECpt3RT9DCpfRA@mail.gmail.com> (raw)
In-Reply-To: <20251023214230.13646-1-canacar@imcan.dev>
[-- Attachment #1: Type: text/plain, Size: 4491 bytes --]
To be perfectly responsible here, I need to state that I have not run the
testsuite, because I couldn't get it working on my machine. It could be
possible for me to set up a virtual environment where I can run the test
suites if required.
Best regards,
Can
On Thu, Oct 23, 2025 at 2:42 PM Can Acar <canacar@imcan.dev> wrote:
> DW_FORM_addr is converted (sign-extended) to a signed value when
> the dwarf size is less than the size of unrelocated_addr, if the
> target architecture "naturally" sign extends an address (bfd.c).
>
> However, the same handling was not done for DW_FORM_addrx. This
> meant that for example, trying to `list` a function with an
> address >= 0x80000000 on (some?) 32-bit mips targets, when
> that address was encoded using DW_FORM_addrx, was broken.
>
> This patch fixes this issue by plumbing read_addr_index_1 into
> unit_head::read_address, which is the function used to extract
> information from DW_FORM_addr, and so it handles this case
> correctly.
> ---
> gdb/dwarf2/read.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 955893c5f0c..e83d6ca38ae 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -15350,12 +15350,14 @@ dwarf2_per_objfile::read_line_string (const
> gdb_byte *buf,
>
> static unrelocated_addr
> read_addr_index_1 (dwarf2_per_objfile *per_objfile, unsigned int
> addr_index,
> - std::optional<ULONGEST> addr_base, int addr_size)
> + std::optional<ULONGEST> addr_base, unit_head *cu_header)
> {
> struct objfile *objfile = per_objfile->objfile;
> bfd *abfd = objfile->obfd.get ();
> const gdb_byte *info_ptr;
> ULONGEST addr_base_or_zero = addr_base.has_value () ? *addr_base : 0;
> + unsigned int ignore_bytes_read;
> + unsigned char addr_size = cu_header->addr_size;
>
> per_objfile->per_bfd->addr.read (objfile);
> if (per_objfile->per_bfd->addr.buffer == NULL)
> @@ -15368,10 +15370,7 @@ read_addr_index_1 (dwarf2_per_objfile
> *per_objfile, unsigned int addr_index,
> objfile_name (objfile));
> info_ptr = (per_objfile->per_bfd->addr.buffer + addr_base_or_zero
> + addr_index * addr_size);
> - if (addr_size == 4)
> - return (unrelocated_addr) bfd_get_32 (abfd, info_ptr);
> - else
> - return (unrelocated_addr) bfd_get_64 (abfd, info_ptr);
> + return cu_header->read_address(abfd, info_ptr, &ignore_bytes_read);
> }
>
> /* Given index ADDR_INDEX in .debug_addr, fetch the value. */
> @@ -15380,7 +15379,7 @@ static unrelocated_addr
> read_addr_index (struct dwarf2_cu *cu, unsigned int addr_index)
> {
> return read_addr_index_1 (cu->per_objfile, addr_index,
> - cu->addr_base, cu->header.addr_size);
> + cu->addr_base, &cu->header);
> }
>
> /* Given a pointer to an leb128 value, fetch the value from .debug_addr.
> */
> @@ -15403,9 +15402,9 @@ dwarf2_read_addr_index (dwarf2_per_cu *per_cu,
> dwarf2_per_objfile *per_objfile,
> {
> struct dwarf2_cu *cu = per_objfile->get_cu (per_cu);
> std::optional<ULONGEST> addr_base;
> - int addr_size;
> + unit_head *cu_header;
>
> - /* We need addr_base and addr_size.
> + /* We need addr_base and header (only some fields of which are used
> later).
> If we don't have PER_CU->cu, we have to get it.
> Nasty, but the alternative is storing the needed info in PER_CU,
> which at this point doesn't seem justified: it's not clear how
> frequently
> @@ -15424,17 +15423,17 @@ dwarf2_read_addr_index (dwarf2_per_cu *per_cu,
> dwarf2_per_objfile *per_objfile,
> if (cu != NULL)
> {
> addr_base = cu->addr_base;
> - addr_size = cu->header.addr_size;
> + cu_header = &cu->header;
> }
> else
> {
> cutu_reader reader (*per_cu, *per_objfile, nullptr, nullptr, false,
> language_minimal);
> addr_base = reader.cu ()->addr_base;
> - addr_size = reader.cu ()->header.addr_size;
> + cu_header = &reader.cu ()->header;
> }
>
> - return read_addr_index_1 (per_objfile, addr_index, addr_base,
> addr_size);
> + return read_addr_index_1 (per_objfile, addr_index, addr_base,
> cu_header);
> }
>
> /* Given a DW_FORM_GNU_str_index value STR_INDEX, fetch the string.
> --
> 2.50.1 (Apple Git-155)
>
>
[-- Attachment #2: Type: text/html, Size: 5521 bytes --]
next prev parent reply other threads:[~2025-10-23 21:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 21:42 Can Acar
2025-10-23 21:44 ` Can Acar [this message]
2025-10-24 13:43 ` Tom Tromey
2025-10-28 1:02 ` Can Acar
2025-10-28 1:03 ` [PATCH v2] " Can Acar
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=CAKB9nm+W+4ZGR_Ahf6j3GEOUm6Qv+k-O--CLECpt3RT9DCpfRA@mail.gmail.com \
--to=canacar@imcan.dev \
--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