port-i386/59402: Inconsistently-guarded macro definitions in ptrace.h header files

[david%gutteridge.ca@localhost]

>Number:         59402
>Category:       port-i386
>Synopsis:       Inconsistently-guarded macro definitions in ptrace.h header files
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 06 23:30:00 +0000 2025
>Originator:     David H. Gutteridge
>Release:        -current
>Organization:
TNF
>Environment:
>Description:
In sys/arch/i386/include/ptrace.h, __HAVE_PROCFS_MACHDEP is not guarded
by _KERNEL, despite the fact it only seems relevant in conjunction with
other situations that are restricted to _KERNEL, e.g., to contextually
reference PROCFS_MACHDEP_NODE_TYPES, or in use in source files that are
implicitly kernel internals. While this seems probably harmless in the
reasonable usages envisioned, it happened to cause a complication
failure with pkgsrc's sysutils/lsof (on i386 only), which, yes,
probably abuses header files (it is kind of a mess).

In comparison, sys/arch/powerpc/include/ptrace.h does guard
__HAVE_PROCFS_MACHDEP with _KERNEL, and does define it immediately
preceding PROCFS_MACHDEP_NODE_TYPES. I also see that
sys/arch/usermode/include/ptrace.h goes to the trouble to
#undef __HAVE_PROCFS_MACHDEP
perhaps to work around this very issue.

It seems for readability as much as anything else to make more sense to
guard it with _KERNEL and move it down to be contiguous with
PROCFS_MACHDEP_NODE_TYPES for i386. It's possible I've missed something
and this isn't correct, of course.

The same situation seems relevant to __HAVE_PTRACE_MACHDEP on i386;
I'm guessing that's why usermode also un-defines it, too.

(Again, while I'm not arguing lsof is "correct" here, making my
suggested change does fix compilation; it has no need of that
particular enum value provided by PROCFS_MACHDEP_NODE_TYPES, anyway.)

>How-To-Repeat:
As above.
>Fix:
As above. (I haven't supplied a patch, but can do so.)