RFC La_aarch64_regs and LD_AUDIT

[Florian Weimer]

* Ben Coyote Woodard via Libc-alpha:

> To fix these two issues I had to break ABI and change the
> La_aarch64_regs structure to match the AAPCS for aarch64 . 
> <https://developer.arm.com/documentation/ihi0042/j/> The structure
> went from:
>
> typedef struct La_aarch64_regs
> {
>  uint64_t lr_xreg[8];
>  uint64_t lr_dreg[8];
>  uint64_t lr_sp;
>  uint64_t lr_lr;
> } La_aarch64_regs;
>
> to:
>
> typedef struct La_aarch64_regs
> {
>  uint64_t    lr_xreg[9];
>  __uint128_t lr_vreg[8];
>  uint64_t    lr_sp;
>  uint64_t    lr_lr;
> } La_aarch64_regs;
>
> I consider this ABI break to be unavoidable.

There is no ABI break as such if the dynamic linker checks the version
returned by la_version and we increase the LAV_CURRENT value.  Existing
audit modules continue to work.

> I don't know what is the right thing to do about SVE is and I think
> that this should be hashed out before we change structure of 
> La_aarch64_regs and break ABI even if it is to fix a problem that
> tools authors are already running into.

My concern is that we should try to come up with a way to use processor
support to save the context, so that we can avoid future LAV_CURRENT
bumps if processor properties related to SVE change.  Ideally, the
dynamic loader would just pass through the data, and the audit module
can use this data using whatever backwards/forwards compatibility
features the ABI offers.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill