Attribute is ignored for now.
It is supposed to check ABI compatiblity and reject loading incompatible images.
Haiku currently do not use multiple ABIs for RISC-V so it is safe to ignore attributes.
PT_RISCV_ATTRIBUTES program header is produced by default in GCC 13 and Clang 17.
Change-Id: I4659e9bacbf34a2a0bc16b34c2aaa37232d700fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6948
Reviewed-by: David Karoly <karolyd577@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This allows Clang builds (linked with our cross binutils) to
at least start runtime_loader and then try to load launch_daemon.
That fails with an infinite loop somewhere...
It will probably be just stubs for the significant future, but,
here it is anyway.
Regarding the naming: Yes, the official name is "aarch64." However,
Linux, FreeBSD, and Zircon all call it "arm64", and so we will do the same.
I've configured it initially to be a Clang-only port, making no
changes to GCC buildtools whatsoever here. We'll see if that sticks,
however.
- This is how it is named in other versions of elf.h (Linux, glibc, possibly more)
- ELF_MAGIC is used by libelf for the same thing, and the defines conflicts,
breaking libelf build on Haiku.
* The Haiku specific notes contain a structure size field, now.
* Change the type of the count and size fields in the Haiku specific
notes to uint32 also for 64 bit ELF. The size field for a note is a
uint32 anyway.
* Add function core_dump_write_core_file(). It writes a core file for
the current thread's team. The file format is similar to that of
other OSs (i.e. ELF with PT_LOAD segments and a PT_NOTE segment), but
most of the notes are Haiku specific (infos for team, areas, images,
threads). More data will probably need to be added.
* Add team flag TEAM_FLAG_DUMP_CORE, thread flag
THREAD_FLAGS_TRAP_FOR_CORE_DUMP, and Team property coreDumpCondition,
a condition variable available while a core dump is progress. A
thread that finds its flag THREAD_FLAGS_TRAP_FOR_CORE_DUMP set before
exiting the kernel to userland calls core_dump_trap_thread(), which
blocks on the condition variable until the core dump has finished. We
need the team's threads to stop so we can get their CPU state (and
have a generally unchanging team state while writing the core file).
* Add user debugger message B_DEBUG_WRITE_CORE_FILE. It causes
core_dump_write_core_file() to be called for the team.
* Dumping core as an immediate effect of a terminal signal has not been
implemented yet, but that should be fairly straight forward.
Make a version of elf.h (assembled from the private header files
elf_common.h, elf32.h and elf64.h, and including Haiku's extensions for
C++) available to applications ported from UNIX.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>