Re: [PATCH v12 2/2] gdb: mips: Add MIPSR6 support

["Maciej W. Rozycki" <macro@orcam.me.uk>]

On Wed, 19 Feb 2025, Milica Matic wrote:

> Introduce new instruction encodings from Release 6 of the MIPS
> architecture [1]. Support breakpoints and single stepping with
> compact branches, forbidden slots, new branch instruction and
> new atomic load-store instruction encodings.

 I have now skimmed over your change and obviously branch decoding is the 
huge update and the most problematic part.  At high level I find new code 
a little bit hairy and hard to follow in some places, and will go over it 
in details double-checking all is in order, and maybe trying to untangle 
it a little.  I won't be able to do it before this coming weekend though 
at which point I'm going on holiday for a fortnight.  Please be a little 
patient meanwhile.

 Also you may have seen my response to an earlier version where I reported 
how I tried to do verification against my 74K Malta only to see it run 
unreliably.  Sadly the 5Kc core card I previously used broke a couple of 
years ago and the replacement newer module does not seem to run equally 
well (also it's 32-bit only while the 5Kc was 64-bit).

 I suspect it just wasn't debugged as thoroughly as the older one, there
are issues with PCI handling both in Linux and even in the YAMON firmware, 
and I think this instability in running GDB verification can be attributed 
to cache coherency maintenance issues in Linux, which can be hairy.  I may 
not have the resources available at hand though to get it sorted quickly.

 It doesn't appear to me that the 74K core card is at fault as I have two 
of them, slightly different and carrying a 74Kc and a 74Kf each, so if it 
was owing to a faulty card, then I imagine they wouldn't behave exactly 
the same.  Also glibc and GCC verification seems more reproducible.  The 
old 5Kc core card was rock-solid, I used it for 20 years until it failed.

 So instead I made an attempt the other day to use alternate test machines 
I have in my remote lab, and that also hit obstacles.  One of the systems 
refused to respond on the serial console.  I've seen it before and it is 
likely owing to its lithium coin cell powering the configuration memory 
having run out of energy, making the system revert to the video console, 
which I have no remote access to.  So I cannot make use of that machine 
for the time being, until the cell has been replaced and configuration 
restored.

 The other system booted just fine and completed reference GDB testing.  
On second iteration however it broke with uncorrectable multiple-bit ECC 
errors reported by DRAM making the system unusable.  The errors persisted 
after a reboot and firmware testing pointed at just one problematic DRAM 
module (out of eight installed total).  I have seen this before as well 
and cleaning contacts and/or reseating the module should clear the issue.  
At worst the module can be removed, reducing system RAM from 256MiB down 
to 224MiB, which should still be fine for the purpose of this testing.

 I have a maintenance visit scheduled to my lab tomorrow, so I'm going to 
address these issues.  I'll report back and, fingers crossed, I should at 
least be able to verify the lack of regressions from your change for older 
systems, possibly by the end of this week.

 I will appreciate your understanding of my constraints.

  Maciej