This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Unreviewed patches
- From: Michael Snyder <msnyder at redhat dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 03 Feb 2003 12:30:53 -0800
- Subject: Re: Unreviewed patches
- Organization: Red Hat, Inc.
- References: <3E39E145.A5B01D17@redhat.com> <20030130.234517.112286807.kazu@cs.umass.edu> <3E3B229D.67F2E805@redhat.com> <20030131.222329.93642824.kazu@cs.umass.edu>
Kazu Hirata wrote:
>
> Hi Michael,
>
> > Yes, thanks. My problem is this: your patch uses a host-order
> > sign-extend to simulate a target-order sign-extend. If the host
> > and target have different byte orders, you lose. That's probably
> > why the simulator uses breg[] to fetch bytes, instead of using
> > wreg and masking.
> >
> > I suggest that it would be comparatively easy to extend the
> > breg[] array so that it would cover at least the first three
> > bytes in the register (and possibly all four, just because
> > it's no extra effort). Something like the attached.
> >
> > Then the code that references breg[] does not need to change.
>
> I understand your concern. But then if GET_W_REG may give a
> byte-swapped value, would the following be endian unsafe?
>
> case O (O_ADD, SW):
> rd = GET_W_REG (code->dst.reg);
> ea = fetch (&code->src);
> res = rd + ea;
> goto alu16;
>
> The addition is done in host-order.
I don't know, other than to say that it evidently works.
However in this case we are fetching a half-word as a half-word.
In the other case, we are fetching a byte as a half-word, and
assuming (incorrectly, I think) that the byte we actually want
will be in the lower half of the half-word.
If you look at the existing code for initializing breg,
it obviously goes to some effort to avoid making that assumption.