Add a few more riscv64 stubs in PAL

[am11]

Also cleaned up some unused code.

[am11]

@jkotas, please take a look.

[am11]

@jkotas, this file was once copied from https://github.com/llvm-mirror/llvm/blob/8b47c17a53d683f313eaaa93c4a53de26d8fcba5/include/llvm/Support/ELF.h in 8f1948e.

In the current llvm tree, it lives at a different location https://github.com/llvm/llvm-project/blob/c444af1c20b35555f2fdb2c1ca38d3f23b2faebd/llvm/include/llvm/BinaryFormat/ELF.h, it is refactored and requires additional dependency StringRef.h. Furthermore, since the code is diverged, new architectures (like loongarch64) were manually added in our copy (which is mostly unused code). It is no longer a drop-in replacement when comparing with upstream.

Except for windows crossdac, which requires struct Elf32_Ehdr definition from this header in elfreader.cpp, we only need the eight machine numbers (EM_xxx) of currently supported architectures in pal.h (ref: https://github.com/torvalds/linux/blob/master/include/uapi/linux/elf-em.h). Should we define them in pal.h and move those struct definitions needed for windows crossdac in elfreader.h/cpp?

struct Elf32_Ehdr is also defined in

runtime/src/native/external/libunwind/include/remote/freebsd-elf32.h

Line 55 in 2d1e29b

typedef struct {

(and 64 bit variant in ..64.h). coreclr uses these freebsd-elfXx.h headers for remote unwinding, and mono also uses it in dwarfwriter on windows:

runtime/src/mono/mono/mini/dwarfwriter.c

Lines 28 to 30 in 2d1e29b

	#ifndef HOST_WIN32
	#include <external/libunwind/include/remote/freebsd-elf32.h>
	#include <external/libunwind/include/remote/freebsd-elf64.h>

but coreclr's elfreader requires a few other definitions on windows which are missing from freebsd-elfXx.h. We can try to make it work if this is a right path forward.

[jkotas]

It is unfortunate that there does not seem to be a standard header with ELF definitions that everybody can use, and everybody ends up creating their own version instead. I guess that we will end up following the same pattern since it is the only option that works.

I think it still makes sense to snap to LLVM version as much as possible, but without introducing dependencies on the rest of LLVM infrastructure like StringRef.h.

I would change the comment on the top of the file to say that this is a subset of the ELF.h from LLVM tree (ie our copy should just have lines deleted, and nothing significant added), delete parts that we do not need, and sync parts that diverged.

[jkotas]

Thanks