Page MenuHomeFreeBSD

libexec/rtld-elf/rtld-libc/Makefile.inc: do not use machdep string functions
ClosedPublic

Authored by fuz on Jul 16 2023, 2:37 PM.
Tags
None
Referenced Files
F86138211: D41050.diff
Sun, Jun 16, 12:05 AM
Unknown Object (File)
May 3 2024, 11:06 AM
Unknown Object (File)
May 1 2024, 11:58 AM
Unknown Object (File)
Apr 30 2024, 4:33 PM
Unknown Object (File)
Apr 30 2024, 4:30 PM
Unknown Object (File)
Apr 30 2024, 4:30 PM
Unknown Object (File)
Apr 30 2024, 9:44 AM
Unknown Object (File)
Apr 26 2024, 1:12 AM
Subscribers

Details

Summary

With ifunc based SIMD dispatch, we cannot use the amd64 assembly
implementations of string functions. Modify rtld to instead use
the generic functions. To avoid an architecture-specific special
case, this change is applied to all architectures.

This change is a prerequisite to and formerly part of D40693.

Sponsored by: FreeBSD Foundation

Test Plan

Passed make tinderbox as part of D40693.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

fuz requested review of this revision.Jul 16 2023, 2:37 PM
This revision is now accepted and ready to land.Jul 16 2023, 3:34 PM

In the commit message, I would emphasize that the change (partially) fixes existing bug where libc use of non-GPR registers or ifunc could break rtld.

I'm sorry for not taking your note into account when landing the commit. I was preparing the commit as you were writing this.

In the commit message, I would emphasize that the change (partially) fixes existing bug where libc use of non-GPR registers or ifunc could break rtld.

We might want to compile rtld with -mgeneral-regs-only to guarantee that the compiler abstains from use of any SIMD registers. This may be more future-proof than -mno-sse and more portable, too.

In D41050#934580, @fuz wrote:

We might want to compile rtld with -mgeneral-regs-only to guarantee that the compiler abstains from use of any SIMD registers. This may be more future-proof than -mno-sse and more portable, too.

Yes we do. Although it perhaps requires per-arch approach.