Sharing ELF definitions between NetBSD userspace and kernel

Hello tech-kern and tech-userlevel,

I would like to discuss ways to implement the following two goals:

Goal 1: To wean userland off the use of <sys/exec_elf.h> (a kernel
  header).

Goal 2: To have a single set of definitions for 'generic' ELF symbols,
  for consistency across NetBSD's userspace and kernel.

Where we are currently:

- Currently, userland code in NetBSD expects the kernel header
  <sys/exec_elf.h> to implement ELF-related symbols.

  However, from the POV of the kernel, almost all of the content of
  this file is clutter -- only a small portion of the content in
  <sys/exec_elf.h> is actually relevant to the kernel.

- The contents of <sys/exec_elf.h> could be grouped into the following
  categories:

  A) Symbols and definitions that need to be consistent across OSes
     for interoperability - the 'generic' set of definitions, further
     subdivided into:

     A1) Symbols that are 'generic' but are NOT used by NetBSD kernel
         code.

     A2) Symbols and definitions that are 'generic', and are used by
     	 the kernel.

  B) NetBSD-local symbols used by userland only.

  C) NetBSD-local symbols needed by both userland and the kernel
     (e.g. the definitions needed for implementing execve(2)).

  D) Kernel-only symbols which are in an #ifdef _KERNEL block.  This
     set is not relevant to this discussion.


For goal 1, we could offer a user header <elf.h>.

Implementing <elf.h> would be straightforward:

- The definitions for the 'generic' sets [A1, A2] are available in
  <sys/elfdefinitions.h> (via external/bsd/elftoolchain), which
  <elf.h> could #include.

- The symbols in set [B] can be moved over from <sys/exec_elf.h>.

Pros:
- Eases porting of third-party code that expects to use an
  <elf.h>.

- Removes the dependency the use of a kernel header.

Cons: (I can't think of a serious con.)


For goal 2, we have the following options (at least):

Option 1: Have <sys/exec_elf.h> include <sys/elfdefinitions.h>
  for 'generic' symbols.

  Something like:
  
    Index: exec_elf.h
    ===================================================================
    RCS file: /cvsroot/src/sys/sys/exec_elf.h,v
    retrieving revision 1.183
    diff -u -r1.183 exec_elf.h
    --- exec_elf.h	18 Nov 2025 13:02:13 -0000	1.183
    +++ exec_elf.h	25 Nov 2025 13:58:30 -0000
    @@ -53,6 +53,8 @@
     #include <stddef.h>
     #endif /* _KERNEL || _STANDALONE */

    +#include <sys/elfdefinitions.h>
    +
     #if HAVE_NBTOOL_CONFIG_H
     #include <nbinclude/machine/elf_machdep.h>
     #else

  This is how some OSes keep userland and the kernel consistent:
  e.g. FreeBSD's userland header <elf.h> includes <sys/elf*.h>, and
  OpenSolaris's <elf.h> brings in <sys/elf.h>.

  The 'generic' definitions currently in <sys/exec_elf.h> can
  then be removed from the file.

  Pros:
  - <sys/exec_elf.h> can become smaller and narrower in focus.

  - Existing third-party code that uses <sys/exec_elf.h> for accessing
    'generic' ELF symbols will continue to compile; such code can
    gradually be adapted to use <elf.h>.

  Cons:
  - This approach requires the Elftoolchain header
    <sys/elfdefinitions.h> to be made available to the kernel build.


Option 2: Manually or semi-automatically maintain all of the 'generic'
  ELF symbols currently present in <sys/exec_elf.h>, say by using a
  script that keeps these symbols in sync with userland.

  Pros:
  - Does not need the kernel build process to change.

  - Application code that uses <sys/exec_elf.h> for 'generic'
    symbols will continue to compile.

  Cons:
  - Non-kernel clutter remains in <sys/exec_elf.h>.

  - Manual steps would be needed to keep the file up to date.

  - Potential for subtle bugs in the future.


Option 3: Like option 2 above but in this option <sys/exec_elf.h> is
  trimmed down to *only* contain the symbols used by the kernel (i.e.
  only the sets [A2], [C] and [D])

  This forces userland code to use <elf.h>.

  Pros:
  - Keeps the kernel header clean and minimal.

  - <sys/elfdefinitions.h> does not need to be available at kernel
    build time.

  - Fewer 'generic' symbols to keep up to date.

  Cons:
  - Breaks third-party code that expects generic ELF symbols to
    be provided by <sys/exec_elf.h>.

  - Extra manual steps to maintain the file (like in option 2).

  - A small amount of symbol duplication remains.


Thoughts/comments?

Regards,
Joseph Koshy | [email protected]