Simplify syscall generation and ABI source file handling for the build.

[bdrewery]

Summary

This is to make the Makefile be more easily extendable for new ABIs.

This also makes several other subtle changes:

• The build now is given a list of ABIs to use based on the MACHINE_ARCH or MACHINE_CPUARCH. These ABIs have a related path in sys/ that is used to generate their syscalls. For each ABI to build check for a ABI.c, MACHINE_ARCH-ABI.c, or a MACHINE_CPUARCH-ABI.c. This matches the old behavior needed for archs such as powerpc* and mips*.
• The ABI source file selection allows for simpler assignment of common ABIs such as "fbsd32" from sys/compat/freebsd32, or cloudabi64.
• Expand 'fbsd' to 'freebsd' everywhere for consistency.
• Split out the powerpc-fbsd.c file into a powerpc64-freebsd32.c to be more like the amd64-freebsd32.c file and to more easily allow the auto-generation of ABI handling to work.
• Rename 'syscalls.h' to 'fbsd_syscalls.h' to lessen the ambiguity and avoid confusion with syscall.h (such as in r288997).
• For non-native syscall header files, they are now renamed to be ABI_syscalls.h, where ABI is what ABI the Makefile is building.
• Remove all of the makesyscalls config files. The "native" one being name i386.conf was a long outstanding bug. They were all the same except for the data they generated, so now it is just auto-generated as a build artifact.
• The syscalls array is now fixed to be static in the syscalls header to remove the compiler warning about non-extern. This was worked around in the aarch64-fbsd.c file but not the others.
• All syscall table names are now just 'syscallnames' since they don't need to be different as they are all static in their own ABI files. The alternative is to name them ABI_syscallnames which does not seem necessary.

Test Plan

universe

[ed]

Hey! Thanks for working on this!

Would it make sense to use 'freebsd' as a name instead of 'fbsd'? If that's too much work, feel free to leave it as is.

[bdrewery]

In D3851#79521, @ed wrote:

Hey! Thanks for working on this!

Would it make sense to use 'freebsd' as a name instead of 'fbsd'? If that's too much work, feel free to leave it as is.

Sure. I almost did but opted to not rename more of the files to achieve that. I will do it anyhow as it is more consistent.

[bdrewery]

Expand 'fbsd' to 'freebsd' everywhere.

[ed]

In D3851#79530, @bdrewery wrote:

Sure. I almost did but opted to not rename more of the files to achieve that. I will do it anyhow as it is more consistent.

Thanks! Really appreciated.

[jhb]

Overall I think this is fine. Long term, it probably makes sense to move the syscall name decoding into libsysdecode which will make this even simpler.

kdump just includes <sys/kern/syscalls.c> directly rather than generating a new file fwiw. It does generate a file for linux system calls.

I imagine libsysdecode would have something like this:

enum ABI { Native, FreeBSD32, Linux, Linux32, CloudABI }

const char *
syscall_name(enum ABI abi, int code)
{
    ....
}

Alternatively you could have separate functions per ABI which might be simpler. It would return NULL for an unknown system call, though possibly it could accept a FILE * and print out '#<val>' for unknown calls.

usr.bin/truss/amd64-freebsd32.c

35 ↗

(On Diff #9265)

FreeBSD/i386 is actually the right thing here. freebsd32 under amd64 is running i386 binaries.

usr.bin/truss/powerpc64-freebsd32.c

31 ↗

(On Diff #9265)

Same with this one, I would leave it as FreeBSD/powerpc since that is the binary being run.

[bdrewery]

In D3851#79706, @jhb wrote:

Overall I think this is fine. Long term, it probably makes sense to move the syscall name decoding into libsysdecode which will make this even simpler.

Yes agreed. Part of this exercise was to see what is really needed for syscall generating and removing the arch-specific Makefile logic. When I noticed the conf files were pretty much all the same I fell into this change. I didn't want to carry any of the arch-specific logic over to libsysdecode. I despise duplicated logic. There's a lot of room for improvement here still for sure.

kdump just includes <sys/kern/syscalls.c> directly rather than generating a new file fwiw. It does generate a file for linux system calls.

I imagine libsysdecode would have something like this:

enum ABI { Native, FreeBSD32, Linux, Linux32, CloudABI }

const char *
syscall_name(enum ABI abi, int code)
{
    ....
}

Alternatively you could have separate functions per ABI which might be simpler. It would return NULL for an unknown system call, though possibly it could accept a FILE * and print out '#<val>' for unknown calls.

This library keeps becoming more interesting and worth doing :)

[jhb]

In D3851#79709, @bdrewery wrote:

In D3851#79706, @jhb wrote:

Overall I think this is fine. Long term, it probably makes sense to move the syscall name decoding into libsysdecode which will make this even simpler.

Yes agreed. Part of this exercise was to see what is really needed for syscall generating and removing the arch-specific Makefile logic. When I noticed the conf files were pretty much all the same I fell into this change. I didn't want to carry any of the arch-specific logic over to libsysdecode. I despise duplicated logic. There's a lot of room for improvement here still for sure.

kdump just includes <sys/kern/syscalls.c> directly rather than generating a new file fwiw. It does generate a file for linux system calls.

I imagine libsysdecode would have something like this:

enum ABI { Native, FreeBSD32, Linux, Linux32, CloudABI }

const char *
syscall_name(enum ABI abi, int code)
{
    ....
}

Alternatively you could have separate functions per ABI which might be simpler. It would return NULL for an unknown system call, though possibly it could accept a FILE * and print out '#<val>' for unknown calls.

This library keeps becoming more interesting and worth doing :)

Yes, I will probably start on it soon (unless you beat me to it). utrace.c and ioctl.c will be a good start followed by the system call names. Next I'd like to start moving random argument decoding functions into it, something like kdump's subr.c. Granted, truss and kdump do slightly different things (e.g. kdump always prints the raw hex value whereas truss includes only unknown bits as a separate item). Will have to think about how to handle that.