Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>
To: Faraz Shahbazker <fshahbazker@wavecomp.com>
Cc: Chao-ying Fu <cfu@wavecomp.com>,
	gdb-patches@sourceware.org,
	"Maciej W . Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH 1/2] [pr gdb/19447] sim: mips: Only truncate sign extension bits for 32-bit target models
Date: Wed, 12 May 2021 14:17:46 -0400	[thread overview]
Message-ID: <YJwbyvTaRGawEKLB@vapier> (raw)
In-Reply-To: <20210504232117.896136-1-fshahbazker@wavecomp.com>

On 05 May 2021 04:51, Faraz Shahbazker wrote:
> 64-bit BFD for MIPS applies a standard sign extension on all addresses
> assuming 64-bit target. These bits are required for 64-bit and can only be
> safely truncated for 32-bit target models. This partially reverts commit
> b36d953bced0a4fecdde1823abac70ed7038ee95

can you verify there are no regressions in `make check` for the various
mips targets & build configs ?

if the tests pass, then i'm fine with the patch.

> ---
> 
> Notes:

these notes should be part of the commit message for posterity

>  	  sim_cpu *cpu = STATE_CPU (sd, cpu_nr);
> -	  sim_cia pc = bfd_get_start_address (abfd);
> -
> -	  /* We need to undo brain-dead bfd behavior where it sign-extends
> -	     addresses that are supposed to be unsigned.  See the mips bfd
> -	     sign_extend_vma setting.  We have to check the ELF data itself
> -	     in order to handle o32 & n32 ABIs.  */
> -	  if (abfd->tdata.elf_obj_data->elf_header->e_ident[EI_CLASS] ==
> -	      ELFCLASS32)
> -	    pc = (unsigned32) pc;
> -
> -	  CPU_PC_SET (cpu, pc);
> +	  /* The 64-bit BFD sign-extends MIPS addresses to model
> +	     32-bit compatibility segments with 64-bit addressing.
> +	     These addresses work as is on 64-bit targets but
> +	     can be truncated for 32-bit targets.  */
> +	  if (WITH_TARGET_WORD_BITSIZE == 32)
> +	    CPU_PC_SET (cpu, (unsigned32) bfd_get_start_address (abfd));
> +	  else
> +	    CPU_PC_SET (cpu, bfd_get_start_address (abfd));

style-wise, it seems like you should have just changed the if() statement
and left the rest of the code alone.  it avoids duplicating the rest of the
logic.
-mike

  parent reply	other threads:[~2021-05-12 18:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-04 23:21 Faraz Shahbazker
2021-05-04 23:21 ` [PATCH 2/2] [pr gdb/19447] sim: mips: Add shadow mappings for 32-bit memory address space Faraz Shahbazker
2021-05-12 18:21   ` Mike Frysinger via Gdb-patches
2021-05-17  7:37     ` Faraz Shahbazker
2021-05-17  7:45     ` [PATCH v2 1/2] [pr gdb/19447] sim: mips: Only truncate sign extension bits for 32-bit target models Faraz Shahbazker
2021-05-17  7:45       ` [PATCH v2 2/2] [pr gdb/19447] sim: mips: Add shadow mappings for 32-bit memory address space Faraz Shahbazker
2021-05-22  0:50         ` Mike Frysinger via Gdb-patches
2021-05-22  0:49       ` [PATCH v2 1/2] [pr gdb/19447] sim: mips: Only truncate sign extension bits for 32-bit target models Mike Frysinger via Gdb-patches
2021-05-11 21:56 ` [PATCH " Mike Frysinger via Gdb-patches
2021-05-12 16:36   ` [EXTERNAL]Re: " Faraz Shahbazker
2021-05-12 18:17 ` Mike Frysinger via Gdb-patches [this message]
2021-05-05 12:18 Faraz Shahbazker
2021-05-05 15:47 Faraz Shahbazker

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=YJwbyvTaRGawEKLB@vapier \
    --to=gdb-patches@sourceware.org \
    --cc=cfu@wavecomp.com \
    --cc=fshahbazker@wavecomp.com \
    --cc=macro@orcam.me.uk \
    --cc=vapier@gentoo.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