Hi Greg, On Tue, Aug 13, 2024 at 11:28 AM Max Filippov <jcmvbkbc@xxxxxxxxx> wrote: > On Mon, Aug 12, 2024 at 9:53 PM Greg Ungerer <gregungerer@xxxxxxxxxxxxxx> wrote: > > On 13/8/24 04:02, Max Filippov wrote: > > > On Sun, Aug 11, 2024 at 7:26 PM Greg Ungerer <gregungerer@xxxxxxxxxxxxxx> wrote: > > >> On 23/3/24 05:54, Max Filippov wrote: > > >>> Althought FDPIC linux kernel provides /proc/<pid>/auxv files they are > > >>> empty because there's no code that initializes mm->saved_auxv in the > > >>> FDPIC ELF loader. > > >>> > > >>> Synchronize FDPIC ELF aux vector setup with ELF. Replace entry-by-entry > > >>> aux vector copying to userspace with initialization of mm->saved_auxv > > >>> first and then copying it to userspace as a whole. > > >>> > > >>> Signed-off-by: Max Filippov <jcmvbkbc@xxxxxxxxx> > > >> > > >> This is breaking ARM nommu builds supporting fdpic and elf binaries for me. > > >> > > >> Tests I have for m68k and riscv nommu setups running elf binaries > > >> don't show any problems - I am only seeing this on ARM. I see the following: - the issue with the change is caused by unaccouncounted AUX vector entry AT_HWCAP2 that is defined for ARM, but not for any other architecture that you tested. - in the original code this off-by-one error resulted in the last entry of the AUX vector being set to zero. Below are the stack dumps from the ARM kernels built by your script, one with my change (left) and the other where this change is reverted (right): argc: 00000001 00000001 argv: 00b8ffde 00b8ffde 00000000 00000000 envp: 00b8ffe4 00b8ffe4 00b8ffeb 00b8ffeb 00000000 00000000 auxv entries: 00000010 00000010 000001d7 000001d7 0000001a 0000001a 00000000 00000000 00000006 00000006 00001000 00001000 00000011 00000011 00000064 00000064 00000003 00000003 00980034 00a00034 00000004 00000004 00000020 00000020 00000005 00000005 00000007 00000007 00000007 00000007 00a40000 00a40000 00000008 00000008 00000000 00000000 00000009 00000009 00984040 00a04040 0000000b 0000000b 00000000 00000000 0000000c 0000000c 00000000 00000000 0000000d 0000000d 00000000 00000000 0000000e 0000000e 00000000 00000000 00000017 00000017 00000000 00000000 0000001f 0000001f 00b8fff6 00b8fff6 0000000f 00000000 00b8ffcc 00000000 00000000 00000000 00000000 00000000 The fix is in correct accounting of space for the AT_HWCAP2 entry. -- Thanks. -- Max
