Re: On upgrading elftoolchain in src/

[jkoshy%netbsd.org@localhost]

cz> - Is there any need today to install elfdefinitions.h in /usr/include?
cz>   What will use it that does not work today (elftoolchain already uses
cz>   its own copy)?

Upstream <libelf.h> uses elfdefinitions.h, as does the rest of the
upstream toolchain (i.e. elfcopy, strings, size, strip, nm, etc).

LibELF-using programs (say in pkgsrc) that are being compiled on NetBSD
would also end up using these symbols.

cz> - The elf stuff that is used by the kernel needs to live in sys/ so
cz>   the kernel will never be able to use elfdefinitions.h (in case in
cz>   the long term we wanted to delete exec_elf.h to avoid duplicated
cz>   definitions).

Noted.

I plan to change upstream so that the file can be placed under <sys/>.

cz> - It is nice and convenient to define the constants as macros together
cz>   with string explanations but readability suffers. If that was a private
cz>   header, that would be a good solution but for system headers brevity
cz>   and clarity trumps convenience IMHO (and most things will not need
cz>   the string explanations which can be accessed using library functions).

Yes.

There is also a subtle portability issue with the way I am using
enumerations which was brought to my attention, and which I intend to fix.

This is that the C standard defines enumerations as having a type of
'int'.  But some values within these enumerations could be larger than
INT_MAX on some platforms, triggering implementation-dependent behavior on
the part of the C compiler.  This may not matter in practice for CLang &
GCC but I would prefer to be ISO C compliant to the extent possible.

So I plan to change the header to use plain '#define's.  The string
constants will be moved somewhere else, say to libelftc (a helper library
used by the rest of Elftoolchain code).

cz> - the elf headers (both the existing one and elfdefinitions.h are too
cz>   long and could be functionally split).

Noted.  Would this be a readability issue or a potential compilation
speed issue?

If the latter it would be easy enough to wrap specific classes of symbols
in #ifdef blocks if needed.

cz> - and yes it sucks not to have a portable elf header across OS's so if
cz>   yours becomes a standard that would be a welcome change... Talking from
cz>   experience (/usr/src/external/bsd/file/dist/src/readelf.h)

Agreed, more compatibility across the BSDs would be a good thing.

Regards,
Joseph Koshy