Add functions to libsysdecode export system call names.

[jhb]

Summary

Add functions to libsysdecode to map system call identifiers to
system call names for different ABIs. All platforms include the
native "freebsd" ABI. Additional ABIs are included on supported
platforms including "freebsd32", "linux", "linux32", and "cloudabi64".

To simplify the implementation, libsysdecode's build reuses the
existing pre-generated files from the kernel source tree rather than
duplicating new copies of said files during the build.

kdump(1) and truss(1) now use these functions to map system call
identifiers to names. For kdump(1), a new 'syscallname()' function
consolidates duplicated code from ktrsyscall() and ktrsyscallret().
The Linux ABI no longer requires custom handling for ktrsyscall() and
linux_ktrsyscall() has been removed as a result.

Test Plan

• Compared before/after output of both kdump and truss on amd64 and i386. For amd64 I compared the output of both amd64 and i386 binaries.

[bdrewery]

lib/libsysdecode/syscallnames.c

41–42 ↗

(On Diff #12023)

This is quite obscure but definitely simpler than the alternatives.

usr.bin/kdump/kdump.c

703–707 ↗

(On Diff #12023)

A downside to inlining more of the ABI-specific C files is that the older style was more centralized for where ABIs are maintained and now it is more spread out in syscallnames.c, kdump.c, and the ABI-specific file. I do see that the old kdump.c did have some linux-specific code though, and still does for errnos. It makes me wonder about cases such as adding cloudabi recently and ensuring nothing is missed. Perhaps libsysdecode should grow an ABI struct with a type defining which ABI is being used similar to the sv_flags&SV_ABI_MASK above. Then kdump can unlearn it. That makes me want sysdecode_freebsd() (and others) to be syscall_name(abi_obj or enum) instead but then we can't use the nice struct initialization.

Anyway it's not a big deal.

[jhb]

usr.bin/kdump/kdump.c

703–707 ↗

(On Diff #12023)

The next change I will send up will deal with errno values. It does make adding cloudabi support to kdump nearly trivial (and it removes linux_ktrsysexit()). Once the errno changes go in I will add cloudabi to kdump. The "raw" libsysdecode branch already has those changes if you want to peruse them on github. However, that branch is in a bit of a busted state as it is still a WIP of moving kdump's subr.c into the library.

So far this library has tried to be a bit more barebones and required the callers to handle what to do for different ABIs. For example, kdump currently uses the 'native' system call names for freebsd32 binaries (which I've kept for now, but doesn't match truss). That is, it requires the caller to manage figuring out which ABI to deal with rather than providing wrappers for that in the library itself. Also, the only ABI-specific bits that I foresee are the name tables and errno mapping tables.

Also, the ABIs were only not duplicated more because kdump didn't support more ABIs. However, it is now much simpler to add new ABIs to kdump.

However, having some sort of enum listing available ABIs and having a single sysdecode_syscallname() that takes the enum might be interesting. If you prefer that I can change this to do it (and the errno conversion methods would use it as well).

[bdrewery]

usr.bin/kdump/kdump.c

703–707 ↗

(On Diff #12023)

It's fine like this for now.

[jhb]

Adding kib@ for some input.

I have one other followup change after this that adds additional ABI-specific behavior (specifically routines for converting errno values between the native ABI and "other" ABIs). I think I like Bryan's suggestion of having an 'abi' parameter to a 'sysdecode_syscallname()' function instead of having separate functions per ABI as I've done here. I would reuse the same parameter in the errno API as well.

My question is what should that 'abi' parameter be? One approach is to simply reuse the 'sv_flags' values from the KTR_PROCCTOR record. Hmm, we don't expose sv_flags directly via kinfo_proc or another kern.proc sysctl (truss uses sv_name). Another approach is to use a dedicated enum declared in sysdecode.h and require clients to map whatever they use (sv_name or sv_flags) to the enum values. The fact that kdump doesn't currently use freebsd32 syscall names probably lends itself to this since kdump in its current form wouldn't be able to directly use sv_flags anyway.

[kib]

In D4823#105084, @jhb wrote:

My question is what should that 'abi' parameter be? One approach is to simply reuse the 'sv_flags' values from the KTR_PROCCTOR record. Hmm, we don't expose sv_flags directly via kinfo_proc or another kern.proc sysctl (truss uses sv_name). Another approach is to use a dedicated enum declared in sysdecode.h and require clients to map whatever they use (sv_name or sv_flags) to the enum values. The fact that kdump doesn't currently use freebsd32 syscall names probably lends itself to this since kdump in its current form wouldn't be able to directly use sv_flags anyway.

sv_flags are not usable to you, There are SV_ABI_XXX and SV_PROC_ABI(), but they are only filled for some ABIs/sysents because programmer did not consider adding a flag or method for the specific behaviour.

I would expect that an abi structure in lib would be an equivalent of the sysent, e.g. for your purposes it probably should point to the errno names array and syscalls names array.

How to build this structure in the usermode is an interesting question, indeed. The sv_name + sv_flags is probably the most reliable way now, but it is not ideal for sure, requiring anybody to pay attention to a field that is not used by kernel for any decision. Also, kernel cannot provide the data like errno name table.

Hm, kernel could export e.g. sv_errtbl, which would allow ktrace to only know about FreeBSD errno names, by using libc syserr array ?

[jhb]

In D4823#105092, @kib wrote:

In D4823#105084, @jhb wrote:

My question is what should that 'abi' parameter be? One approach is to simply reuse the 'sv_flags' values from the KTR_PROCCTOR record. Hmm, we don't expose sv_flags directly via kinfo_proc or another kern.proc sysctl (truss uses sv_name). Another approach is to use a dedicated enum declared in sysdecode.h and require clients to map whatever they use (sv_name or sv_flags) to the enum values. The fact that kdump doesn't currently use freebsd32 syscall names probably lends itself to this since kdump in its current form wouldn't be able to directly use sv_flags anyway.

sv_flags are not usable to you, There are SV_ABI_XXX and SV_PROC_ABI(), but they are only filled for some ABIs/sysents because programmer did not consider adding a flag or method for the specific behaviour.

I would expect that an abi structure in lib would be an equivalent of the sysent, e.g. for your purposes it probably should point to the errno names array and syscalls names array.

How to build this structure in the usermode is an interesting question, indeed. The sv_name + sv_flags is probably the most reliable way now, but it is not ideal for sure, requiring anybody to pay attention to a field that is not used by kernel for any decision. Also, kernel cannot provide the data like errno name table.

Hm, kernel could export e.g. sv_errtbl, which would allow ktrace to only know about FreeBSD errno names, by using libc syserr array ?

Well, for now I've just moved the errno tables from truss into libsysdecode in my followup change (and then added wrapper functions to handle conversions). One nicer property of this is that I've changed truss to always print the raw errno value as the ABI sees it and then the string interpretation of that error converted to a FreeBSD errno. In that sense the new truss reports the "true" error value that the application sees (right now truss reports the converted errno value).

However, for now my question is how to describe the ABI. I think a simple enum will work for now:

enum sysdecode_abi {
    FREEBSD,
    FREEBSD32,
    LINUX,
    LINUX32,
    CLOUDABI64
};

[jhb]

• Add an ABI enum and collapse the per-ABI name functions to a single function.
• Add an UNKNOWN_ABI placeholder.
• Update kdump for the ABI enum.
• Update truss for the ABI enum.
• Add a default case to appease -Wswitch.
• Compile.
• Spelling mistake.

[bdrewery]

Thank you. I like this API much more and think it will be easier to maintain for consumers.