Removed LLD and JIT related parts - JIT is out of my scope, and LLD will be in an additional patch.
Fixed additional remarks.

In D128612#3620911, @MaskRay wrote:

In D128612#3618167, @gbenyei wrote:

In D128612#3617955, @MaskRay wrote:

lld/ELF change should be dropped from this change. Don't use config->endianness.
I feel sad that for little-endian users who don't use big-endian, every write now is slightly slower due to a check ;-)

Hi, I'm not sure I get it. How will we have a fully functional toolchain, if I don't implement the lld/ELF part?
In LLVM, unlike in GCC, target related decisions happen in runtime. I think it's a high level design decision. While I can understand the pain of LE developers getting a slightly slower linker due to endianness checking, I sure will feel the pain of a BE developer not having a linker...

Please explain why I shouldn't use config->endianness?

See PPC64.cpp. See D96188 how I added aarch64_be support. A set of representative tests should be picked with be tests.
If llvm-project consensus is that we will add big-endian support, I can handle lld/ELF part. I am mostly concerned with this scenarios that some RISC-V folks click LGTM, and the change lands with no test in some areas, or the code somewhat breaks local convention.

Many of the changes in this patch probably should be split. llvm-objcopy and JIT changes definitely needs appropriate tests and the suitable domain reviewers.

In D128612#3617955, @MaskRay wrote:

lld/ELF change should be dropped from this change. Don't use config->endianness.
I feel sad that for little-endian users who don't use big-endian, every write now is slightly slower due to a check ;-)

In D128612#3617906, @jhenderson wrote:

Objcopy aspects look good, thanks.

Thanks, Craig. Updated the patch with your remarks.

IdentifierInfo change LGTM, based on the discussion here: