On 28.05.2019 20:08, Martin Husemann wrote: > On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote: >> Well, if we are only to consider new registers, then we're talking about >> 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state >> register, multiply by two... 114 PT_* requests? > > Integers are plenty, but the core file format issue makes this aproach > unusable anyway. > > Still I think we should not create too many random processor register groups. > For performance reasons PT_GETREGS should be grouped into a single system call and separated from FPU/DB/similar/ones. FPU registers can be handled separately. I defer the decision to x86 maintainer how to process them. As mentioned, there is no performance issue here (1-2-3 calls make no difference). > We already have very strange ones (XMMREGS and VECREGS). Maybe we should just > have one ALLREGS thing (identical to the core note) and then discuss how > to properly make that sanely versioned and self describing? > In core there is no ALLREGS, but separated register sets. ALLREGS has some issues as e.g. DB registers have different policy with accessing them from userland, it's not part of core(5) file, not part of mcontext. Accessing individual registers is similar to what we had originally in pre-NetBSD times. There was a struct shared between userland debugger and kernel (so called userdata). There were dedicated calls to access the registers that struct with PT_READ_U/PT_WRITE_U, but as it didn't match modern kernels it was abandoned back in the days. Something similar with per-register access can still be achieved with reading /proc/*/*regs (but likely it has 0 users.. and might not work). > Martin >
Attachment:
signature.asc
Description: OpenPGP digital signature