Page MenuHomeFreeBSD

[PowerPC] libc backwards compatibility shim for auxv change
ClosedPublic

Authored by bdragon on Jan 8 2020, 11:02 PM.

Details

Summary

As part of the FreeBSD powerpc* flag day (1300070), the auxv numbering was changed to the common format.

See D20799 for more details on that change.

While the kernel and rtld were adapted, libc was not, so old dynamic binaries broke for reasons other than the ABI change on powerpc64.

Since it's possible to support nearly everything regarding old binaries by adding compatibility code to libc (as besides rtld, it is the main point where auxv is digested), we might as well provide compatibility code.

The only unhandled case remaining should be "new format libraries that call elf_aux_info() which are dynamically linked to by old-format binaries" in my reckoning.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

I'm wondering what happens with libc's use of elf_aux_info...

lib/libc/gen/auxv.c
77 ↗(On Diff #66521)

I'd be tempted to invert this flag so it lands in bss by default.

libc itself calls _elf_aux_info directly instead of the weak elf_aux_info, so will *never* call _powerpc_elf_aux_info.

lib/libc/gen/auxv.c
77 ↗(On Diff #66521)

Good point.

Additionally, I was wondering if it would be worth it to use a stack variable in init_aux to track type 23, so we could have the default value mean new format and avoid having to write to the variable except in the backwards compatibility case. Is that worth it or will the need to change the variable by default get lost in the noise?

lib/libc/gen/auxv.c
77 ↗(On Diff #66521)

That's probably not going to matter in practice. I was just interested in keeping the bytes out of libc and static binaries (not that it really matters in the grand scheme of things.)

Invert the variable so it ends up in bss.

This revision is now accepted and ready to land.Jan 19 2020, 9:20 PM