Provide some more information for userland core dumps

[emaste]

Summary

Previously the log message indicated only "(core dumped)" if a core was
successfully created, or nothing if it was not. This provides
insufficient information to faciliate debugging. Dtrace is no help as
coredump() is static and we cannot find the return value via fbt.
Expand the log message to include error return value information.

[emaste]

I did this in 2017 when trying to track down why a core dump failed and it's just been sitting around. Discussed with @jhb on IRC. John suggested adding an SDT probe for the return value in the default case which seems like a useful addition but could be a followup.

[kib]

Why not print the numeric error code. 'other error' is also not too informative.

[markj]

Dtrace is no help as coredump() is static and we cannot find the return value via fbt.

@christos' work gets us a large part of the way there now - you can at least trace coredump()'s entry and return: dtrace -n 'kinst::coredump:entry {printf("%s", curthread->td_name);} kinst::coredump:return {}' prints

0  73091                      sigexit:137 cat
1  73093                      sigexit:390

if I send SIGQUIT to cat. What doesn't work yet is getting the return value, but it's possible to access arbitrary registers from the probe context, so it's "just" a matter of knowing which one.

In any case, I think this change is useful.

sys/kern/kern_sig.c

3636

Handle ENOSYS as well?

3651

Add a break here?

[jhb]

The raw errno value would require a stack buffer to hold the formatted string which is my guess as to why it's just "other error" (and the original version Ed had didn't have the other error text even). I think if the other error case can be figured out via dtrace that using a static string to avoid the stack buffer is an ok compromise.

[markj]

Is there any reason not to commit this?

[markj]

sys/kern/kern_sig.c

3647

I believe coredump() will return ENOTCAPABLE if the program is in capability mode and kern.capmode_coredump=0. It would be useful to have a case here for that, with an error message that points users at the sysctl.

[jhb]

I would definitely like this committed.