Hi, this works for me. I successfully cross-compiling llvm from x86 to riscv by applying this patch. Thanks a lot.
But you may still need to wait for paulkirth's comment to verify that it works on Fuchsia's clang CI as well.

Remove unused parameter.

Revert partial clang format.

Fix the variable's name.

Include the recent commits and update the alignment check.

LGTM

Please update this file as well and clang format the codes.
llvm/lib/ExecutionEngine/JITLink/riscv.cpp

In D119804#3333467, @rengolin wrote:

In D119804#3333462, @rengolin wrote:

I think you forgot to upload the new diff for the GCC comment. It's looking the same as before for me.

Hm, there wasn't any. But I did get a comment on the email that I wanted to reply to and it isn't here. Won't change the acceptance of the patch, it's more as FYI.

If you're compiling with GCC, you can use architecture options for your target, and the compiler driver will detect everything that it needs

This is a common thread between Clang and GCC.

In GCC, the target is defined at compile time, so if you use target-gcc, all of the options are already chosen. Paths, headers, libraries, even sysroot is already set.

Clang also has target-clang (as a symlink to clang), but that's a shortcut to clang -target target, which may have some headers but doesn't have libraries, sysroot and may not get the right path (if the platform compiler is GCC and compiled in unexpected ways).

That is why we need the other flags and why this document was written in the first place.

We have debated for years if we want to have a default LLVM sysroot+libs+headers, and some side projects have started in that direction, but we shouldn't use a different toolchain from the system one if we want to link with objects compiled with the system compiler (statically or dynamically).

In FreeBSD, Apple and OpenMandriva, Android, the system compiler is clang, so all libraries, paths and the sysroot should be easy to find and known, and clang does what you expect, too.

But on other Linux distros, Windows and systems where the system toolchain isn't clang, you'll have that problem again.

In D119804#3333462, @rengolin wrote:

I think you forgot to upload the new diff for the GCC comment. It's looking the same as before for me.

(PS: this is one of the problems of Phab to me, it can be confusing with git diff + patch + upload).

Include the recent commits and fix the test.

Reverted in the https://github.com/llvm/llvm-project/commit/051f7cdcd2ccfb54f5030e16d0026057d203ddd2 due to build failure.

Hi, StephenFan, I have a question in the inline comment.
Would you be so kind to explain it to us?

Update the format.

LGTM

Hi, could you please update the code comments on R_RISCV_BRANCH in llvm/include/llvm/ExecutionEngine/JITLink/riscv.h
at the same time?

Address the comments.

fix the arc diff issue

Sorry about arc diff issue. I will update it later.

address the comments and include the recent commits.

Include the recent commits.

Include the recent commits.

Add test cases and address the comments.

In D117082#3236340, @jrtc27 wrote:

You can write tests just fine in assembly. Use .reloc if needed. You don't need .eh_frame for that.

Address the comments.

Fix the behavior after extractBits function's update.

Include the recent commits.

Include the recent commits.

Add prefix for hexadecimal numeric.