Add standard ELFDATANONE constant

Add missing ELF constants

Move elf_image_arch to elf_common.h

Add SYSV and HAIKU ELFOSABI values.

Currently ELFOSABI_HAIKU is mapped to ELFOSABI_NONE, matching the
existing BeOS and Haiku binary targets.

One possible direction for ELFOSABI would be allocating a new
ELFOSABI_HAIKU value, and using this for all future platforms (gcc4-x86,
x86-64, ARM, MIPS, etc). This would allow for control over the
EI_ABIVERSION field, which could be used to define per-machine ABI
versioning. Examples would be ARMv6+softfloat, ARMv7, etc.

There are alternative approaches to providing this differentiation,
but to do so at the binary wrapper level is considerbly simpler than
resolving symbols inside of ELF binaries to determine exact ABI flags.

For comparison, Mach-O uses a 32-bit cpu and cpu_subtype fields, where
the 'cpu' field defines the general architecture family (ARM, x86, etc),
and the subtype is used to define specific subtypes (ARMv6, ARMv7),
along with two bytes dedicated for feature flags.

See also:
http://fxr.watson.org/fxr/source//osfmk/mach/machine.h?v=xnu-2050.18.24

Using the EI_ABIVERSION field with ELF may be one reasonable way to
implement similar functionality while maintaining standard ELF
compatibility. As an alternative, one could extend the ELF or FatELF
headers; the continued value of ELF is in leveraging existing tooling,
rather than any of the notions of cross-OS binary compatibility under
which ELF was specified. FatELF itself is not (yet?) a standard, which
also gives us some leeway to make changes to it before deployment.

Add standard ELFOSABI_* constants

Define ELF_DATA, evaluates to the host value.

This is based on the header suggestions in #8520

Add missing standard ELF constants

Fixed compilation of C code using ELF headers.

Support ELF64 in the kernel.

This has been done by adding typedefs in elf_common.h to the correct ELF
structures for the architecture, and changing all Elf32_* uses to those
types. I don't know whether image loading works as I cannot test it yet,
there may be some 64-bit safety issues around. However, symbol lookup for
the kernel is working correctly.

Changed the boot ELF code to use templates and added ELF64 support.

The actual implementation of the ELF loading methods have been put into
an ELFLoader template class that takes a single template parameter, which
is a structure containing all the necessary ELF typedefs. It's a bit
verbose, but I thought it was a neater solution than using a bunch of
standalone functions with a huge number of template parameters. There is
no change to code outside of elf.cpp, the ELF32/ELF64 differences are
handled internally.

Added ELF64 headers, common ELF32 and ELF64 definitions moved to elf_common.h.

Move elf_image_arch to elf_common.h

Add SYSV and HAIKU ELFOSABI values.

Currently ELFOSABI_HAIKU is mapped to ELFOSABI_NONE, matching the
existing BeOS and Haiku binary targets.

One possible direction for ELFOSABI would be allocating a new
ELFOSABI_HAIKU value, and using this for all future platforms (gcc4-x86,
x86-64, ARM, MIPS, etc). This would allow for control over the
EI_ABIVERSION field, which could be used to define per-machine ABI
versioning. Examples would be ARMv6+softfloat, ARMv7, etc.

There are alternative approaches to providing this differentiation,
but to do so at the binary wrapper level is considerbly simpler than
resolving symbols inside of ELF binaries to determine exact ABI flags.

For comparison, Mach-O uses a 32-bit cpu and cpu_subtype fields, where
the 'cpu' field defines the general architecture family (ARM, x86, etc),
and the subtype is used to define specific subtypes (ARMv6, ARMv7),
along with two bytes dedicated for feature flags.

See also:
http://fxr.watson.org/fxr/source//osfmk/mach/machine.h?v=xnu-2050.18.24

Using the EI_ABIVERSION field with ELF may be one reasonable way to
implement similar functionality while maintaining standard ELF
compatibility. As an alternative, one could extend the ELF or FatELF
headers; the continued value of ELF is in leveraging existing tooling,
rather than any of the notions of cross-OS binary compatibility under
which ELF was specified. FatELF itself is not (yet?) a standard, which
also gives us some leeway to make changes to it before deployment.

Add standard ELFOSABI_* constants

Define ELF_DATA, evaluates to the host value.

This is based on the header suggestions in #8520

Add missing standard ELF constants

Fixed compilation of C code using ELF headers.

Support ELF64 in the kernel.

This has been done by adding typedefs in elf_common.h to the correct ELF
structures for the architecture, and changing all Elf32_* uses to those
types. I don't know whether image loading works as I cannot test it yet,
there may be some 64-bit safety issues around. However, symbol lookup for
the kernel is working correctly.

Changed the boot ELF code to use templates and added ELF64 support.

The actual implementation of the ELF loading methods have been put into
an ELFLoader template class that takes a single template parameter, which
is a structure containing all the necessary ELF typedefs. It's a bit
verbose, but I thought it was a neater solution than using a bunch of
standalone functions with a huge number of template parameters. There is
no change to code outside of elf.cpp, the ELF32/ELF64 differences are
handled internally.

Added ELF64 headers, common ELF32 and ELF64 definitions moved to elf_common.h.