This patch adds a test case to test dynamic register sets. This tests for the availability of certain register sets and query their registers accordingly.
Can you explain the logic for the values here?
You don't need the brackets around i for % (i).
Is it slightly more strict if we have one loop that reads then writes?
for i in range(32): write read
Since we write the same value, if you write them all then read them all you aren't totally sure that each one is lined up right. Then again I'm sure you've tested sve register writes elsewhere.
Anyway, a single loop for each would be a bit neater.
If you move all this code from after the for, into the for loop, you could skip having the bools per register set.
(I'm not familiar with SVE assembly but anyway..)
Is the .b/.h/.s etc. pattern specific or does it not matter?
Same here, is the p0/p5/p10/p15 pattern affecting values used in the test or just for fun? (which isn't a bad thing)
This appears to be defined but not set.
Should there be a #ifndef HWCAP_SVE above too?
Would be neat to do these vars like:
unsigned int mte_is_enabled = hwcap2 & HWCAP2_MTE;
We are using SVE read/write in this test to make sure we do not overlap register offsets while calculating offsets for the dynamic registers. Further dynamic register sets should also be readable.
P reg sets predicate lanes. P0 will have all lanes set while P5 will have no lanes set. These are just random values testing read/write.
I think you are right. If we do a read after write in a single loop we ll be doing 64 ptrace calls on lldb-server side. More the better.
I was actually trying to see whether what cpuinfo reports and what is reported by prctl is same or not.
Replied in comment below.
I copied this from SVE test case that I wrote last year.
P is a predicate register and ptrue/pfalse instruction is used to set a predicate lane with a pattern. pattern is decide based on size specifier, b, h, s and d.
if size specified is b all lanes will be set to 1. which is needed to set al bytes in a Z registers to the specified value.
We are setting p0, p5, p10 and p15 to enable all lanes other p registers are not enabling all lanes thats why they were not used as predicate for setting Z registers in following lines which set a constant value to Z register byte size elements.
Ack. I ll adjust these as per your suggestion below.
Most distros have now backported ptrace.h to include HWCAP_SVE but other two are still in the process.
I would put that in a comment to save some time for those unfamiliar with SVE.
I'd put that in a comment. Enough for someone triaging a failure to know what's arbitrary numbers and what's very specific.
Some python nits otherwise the test looks good.
These messages are printed on assert failure. So this one would be "Expected a register named...".
For this and the other instances of this pattern you an make it one string like:
self.expect("register read z%i" % i, ...
Do we need an ffr read if we have a read/write below?
These if not could be self.assertFalse.
I am kinda old school so choose to write + will fix :)
Yes self.assertTrue I guess. Will fix.
Ok but then should the second r/w be of a different value?
program writes A - we read A, so the read works
Second read/write was different value but a fixed value was being used for testing all z/p registers. I have updated this rev to add unique values which are still different from what is written by the main.c
Move the closing ) onto the first line. Also I'd indent the line below like:
self.assertTrue(self.isAArch64SVE(), 'LLDB enabled AArch64 SVE register set when it was disabled by target.') self.....
(applies to the next two as well)
Should be isAArch64PAuth
These are unused since we get it from the cpuinfo, then you can inline the sve check in the if below.
I find this combination of %-formatting and string concatenation unsettling. Just use % for the whole string?