Re: ppc64 XER potentially ignored/not setting

[Fabiano Rosas]

Kyle Lehman <klehman9@comcast.net> writes:

> On 11/16/21 02:26, Thomas Huth wrote:
>
>>> Upon execution r3 is set correctly to 0xffffffffff823456, however ca 
>>> is not set within the XER when it should be.
>> 
>> Could you reproduce the issue with a stand alone binary, too? ... it 
>> would be interesting to know whether the problem is in the GDB interface 
>> or in the emulation part...
>> 
>>   Thomas
>
> Upon further review, turns out this is mostly user error on my part.
>
> When I built the latest qemu, I started immediately manually debugging 
> it with standard human readable GDB to see if it solved the issue.  So I 
> did my steps in the test, looked at register 'xer' and noticed it still 
> sat at 0.  Which where my original post comes from.
>
> In the mean time, I then moved to implement more features with my 
> automated testing which uses the machine interface format of GDB.  There 
> I noticed register x 69 (XER) was indeed being modified.  Great!
>
> This was confusing, but at least I narrowed something down.  This was 
> until I was back into manual GDB side of things, did a register dump and 
> noticed 'xer' was listed there twice.  One had 0, the other held a value.

The reason some SPRs are listed twice is that we provide GDB with
a separate XML register definition specific for the SPRs.

The duplication happens because GDB has its own view of the
architecture's registers (in binutils tree at
gdb/features/rs6000/power-core.xml), which QEMU mimics at
gdb-xml/power-core.xml. Since GDB is mostly an userspace debugging tool,
it does not have a separate XML definition for SPRs. What it does is
define the few that are relevant for userspace along with the general
purpose ones.

So GDB defines XER, LR and CTR along with the GPRs and we later define
them again along with all the other SPRs.

>
> So, in short, I was looking at the duplicated xer set to 0 instead of 
> the "real" one within GDB.  Embarrassing to say the least that I didn't 
> notice it sooner, but in my defense the old noggin sometimes gets into a 
> haze staring at these things.

Not embarrassing at all! QEMU/GDB shouldn't be showing duplicated stuff,
specially if the values differ.

Perhaps QEMU could filter out the few that are being registered twice...

>
> Emulation side of things appears fine, I ran our test cases that put XER 
> through its paces and the results tie out perfectly.
>
> To recap:
> 1) XER emulation fine (for our test cases)
> 2) Register setting/getting from x 69 using GDB MI works fine
> 3) xer shows up twice in normal GDB mode, with one that appears attached 
> to nothing.  Setting xer in this mode (set $xer=whatever) does in fact 
> get picked up properly within emulation
>
> Thank you for all the effort.  Definitely not an easy ISA to emulate and 
> can make your head spin sometimes.
>
> Kyle