On Tue, Mar 7, 2023 at 7:28 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Thu, Mar 2, 2023 at 11:06 AM Grant Seltzer Richman > <grantseltzer@xxxxxxxxx> wrote: > > > > Hi everyone, > > > > I'm writing a uprobe program that I'm attaching to a function in a go > > program on arm64. The function takes a float and as such loads the > > parameters via 64-bit floating point registers i.e. `D0`. > > > > However, the struct pt_regs context that uprobe programs have access > > to only has a single set of 31 64-bit registers. These appear to be > > the regular general purpose integer registers. My question is - how do > > I access the second set of registers? If this question doesn't make > > sense, am I misunderstanding how arm64 works? > > > > cc'ing Dave, as he was looking at this problem in the past (in the > context of accessing xmm registers, but similar problem). > > The conclusion was that we'd need to add a new helper (kfunc nowadays) > that would do it for BPF program. Few things to consider: > > - designing generic enough interface to allow reading various > families of registers (FPU, XMM, etc) in some generic way > - consider whether do platform-specific or platform-agnostic > interface (both possible) > - and most annoyingly, we'd need to handle kernel potentially > modifying FPU state without (yet) restoring it. Dave investigated > this, and in some recent kernels it seems like kernel code doesn't > necessarily restore FPU state right after it's done with it, and > rather sets some special flag to restore FPU state as kernel exits to > user-space. Thanks for this info Andrii! I think your first couple points are manageable but I'm not familiar with FPU context switching. Will read up on it, and Dave if you're willing to give some guidance I'd happily put in the work to get this helper introduced! > > Hopefully Dave can correct me and fill in details. > > > > Thanks so much, > > Grant
