Page MenuHomeFreeBSD

libc: don't needlessly add vfork.o to NOASM
ClosedPublic

Authored by brooks on Dec 5 2023, 7:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
May 8 2024, 1:24 PM
Unknown Object (File)
May 8 2024, 1:24 PM
Unknown Object (File)
May 8 2024, 11:43 AM
Unknown Object (File)
Feb 2 2024, 6:34 PM
Unknown Object (File)
Jan 20 2024, 12:25 PM
Unknown Object (File)
Dec 23 2023, 6:01 AM
Unknown Object (File)
Dec 15 2023, 2:03 AM
Unknown Object (File)
Dec 6 2023, 9:07 PM
Subscribers

Details

Summary

For architectures where vfork.S was named Ovfork.S this was needed, but
it was always pointless here as an entry in either MDASM or NOASM is
equivalent.

Sponsored by: DARPA

Diff Detail

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

Event Timeline

brooks requested review of this revision.Dec 5 2023, 7:09 PM

Are you sure about amd64? There is the arch-specific manually written vfork.S.
Does the patch rely on vfork.S in MD directory to override vfork.s automatically generated for the syscall?

In D42914#978872, @kib wrote:

Are you sure about amd64? There is the arch-specific manually written vfork.S.
Does the patch rely on vfork.S in MD directory to override vfork.s automatically generated for the syscall?

Yes, I'm sure. The presence of vfork.S in MDASM prevents the default stub from being generated in the same loop that handles NOASM. I'm pretty sure they only reasons these were there is that i386 put the real implementation in Ovfork.S and then porters copied it around.

This revision is now accepted and ready to land.Dec 6 2023, 12:59 AM
This revision was automatically updated to reflect the committed changes.