PC and PSR on 26-bit ARM

PC and PSR on 26-bit ARM

[Ben Harris]

I'm trying to make GDB work happily on NetBSD/arm26, which runs on ancient
ARM processors, where the PC and PSR share R15.  As far as I can tell, the
code in arm-linux-nat.c, when fetching registers subprocess on a 26-bit
CPU, puts the PC in registers[PC_REGNUM], and the PC+PSR in
registers[PS_REGNUM].  When putting registers back into the process, it
sets R15 (PC+PSR) from registers[PC_REGNUM] and ignores
registers[PS_REGNUM].

I suppose my question is: is this the intended behaviour?  i.e. should I:
(1) do the same on NetBSD,
(2) accurately emulate a 32-bit CPU in 26-bit mode (splitting and
    merging PC and PSR at the subprocess interface), or
(3) present GDB with the real state of the CPU?

I think my preference is for (2), since this saves complexity in the rest
of GDB.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL: http://www.netbsd.org/Ports/arm26/ >

Re: PC and PSR on 26-bit ARM

[Philip Blundell]

>I'm trying to make GDB work happily on NetBSD/arm26, which runs on ancient
>ARM processors, where the PC and PSR share R15.  As far as I can tell, the
>code in arm-linux-nat.c, when fetching registers subprocess on a 26-bit
>CPU, puts the PC in registers[PC_REGNUM], and the PC+PSR in
>registers[PS_REGNUM].  When putting registers back into the process, it
>sets R15 (PC+PSR) from registers[PC_REGNUM] and ignores
>registers[PS_REGNUM].

I don't think the 26-bit support for arm-linux has ever really been tested, so 
you probably don't want to put too much faith in it.  What you've described 
doesn't really sound like the right thing to me; the fetching side is OK, but 
when it writes registers back into the process I think it needs to combine 
registers[PC_REGNUM] and registers[PS_REGNUM] in order to get the correct R15 
value.

p.

Re: PC and PSR on 26-bit ARM

[Andrew Cagney]

> I'm trying to make GDB work happily on NetBSD/arm26, which runs on ancient
> ARM processors, where the PC and PSR share R15.  As far as I can tell, the
> code in arm-linux-nat.c, when fetching registers subprocess on a 26-bit
> CPU, puts the PC in registers[PC_REGNUM], and the PC+PSR in
> registers[PS_REGNUM].  When putting registers back into the process, it
> sets R15 (PC+PSR) from registers[PC_REGNUM] and ignores
> registers[PS_REGNUM].
> 
> I suppose my question is: is this the intended behaviour?  i.e. should I:
> (1) do the same on NetBSD,
> (2) accurately emulate a 32-bit CPU in 26-bit mode (splitting and
>     merging PC and PSR at the subprocess interface), or
> (3) present GDB with the real state of the CPU?
> 
> I think my preference is for (2), since this saves complexity in the rest
> of GDB.

GDB doesn't really care what happens.  It has mechanisms (if only Arm 
was multi-arched) to handle cases such as 2.

Do arm26 and arm32 run the same binaries?  If they do then you probably 
want a consistent interface with carefully documented semantics. 
Otherwise, the best rule I know of is ``don't lie'' - present GDB with 
the real raw CPU state.

Andrew

Re: PC and PSR on 26-bit ARM

[Ben Harris]

On Fri, 26 Oct 2001, Andrew Cagney wrote:

> Do arm26 and arm32 run the same binaries?

Yes, with an appropriately careful compiler (ours is).

>  If they do then you probably
> want a consistent interface with carefully documented semantics.

That's what I'm going for.  Actually, I'm wrapping the interface in a
couple of functions so that targets will be able to get it right easily.
I'll send them to gdb-patches in a moment.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL: http://www.netbsd.org/Ports/arm26/ >