In D104183#2815292, @compnerd wrote:

Some platforms (e.g. WoA) do require thumb-only compilation. Can we conditionalize this on whether we are building for ARMv6 or not?

ping,

http://sprunge.us/FJzZXL is a file from harfbuzz and it warns

In D102872#2773106, @DavidSpickett wrote:

I assume this is caused by the removal of the specific NativeRegisterContextLinux_mips and you are building lldb on MIPS but you're going to connect to another debug server (gdb, custom stub etc.).

The problem with doing it this way is then if you build on a supported platform e.g. AArch64 NativeRegisterContextLinux_arm64 we then have two copies of CreateHostNativeRegisterContextLinux. Somehow this isn't an error on my system, and it picks up the one you've added. Meaning that you can't debug a simple hello world.

See the comment in lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h. (though again I'd have expect a hard linker error but anyway) Also the reason CI didn't fail is that lldb is disabled for both of the builds.

I can see the utility in allowing people to build at least lldb (client) on any platform. Perhaps we surround this in the #ifdef that the old mips register context used? Or modify our cmake to allow lldb-server to be disabled. (easier said than done)

LGTM

In D102535#2760944, @MaskRay wrote:

In D102535#2760911, @jrtc27 wrote:

In D102535#2760899, @MaskRay wrote:

In D102535#2760807, @jrtc27 wrote:

I view this as a bug in whatever calls the assembler; it should be passing -mno-relax, just as it needs to pass -fPIC as appropriate.

I'll use the -g analogy. clang -S -g emits debug info and leaves a .debug_line marker so that the assembler knows it needs to synthesize debug info and should not synthesize .debug_info from ELF symbols.
The assembler doesn't need -g to function.

For .option nopic, I agree it is not useful.

The two aren't comparable. Relaxation affects assembling and not code generation. Debug info affects code generation to emit all the information that's otherwise lost (the assembly doesn't have a copy of your source code...). Even PIC is more useful than .option norelax, as it affects what instructions get used to lower global addresses etc.

I think the -Wa,-mno-relax argument is justified if code generation cannot affect relaxation (which I am unsure).

Can GCC base assembly emission decisions on -mno-relax?

@MaskRay I dont find this in main branch yet, anything pending on me ?

once you fix the clang-format issue reported this looks good to me.

@MaskRay how should be proceeed here

0073c293a401774ac96b4b3d27f05e13f379f98e has fixed it.

Can someone review this please?

this is because warning were disabled during cmake tests

it works with python3 too, perhaps it would be good to ask for python3 instead

this is no longer needed.

I am still seeing build failures in NATIVE/llvm-config when I am cross building clang for say aarch64 on a x86_64 host. Even when I specify -DLLVM_ENABLE_TERMINFO=OFF, it still goes and pokes for these ncurses libs on build host and adds them to linker cmd. Since my target rootfs is set to not have these libs the final link fails to find -lterminfo rightly. Surprisingly, non NATIVE parts work ok and seem to respect LLVM_ENABLE_TERMINFO settings. Any insights ?

Can we get this on clang 12 release branch as well ?

In D85095#2400738, @ldionne wrote:

I don't understand why this has its place in libc++. Shouldn't this be in glibc instead?

it should have been after including syscall.h

Add comments in source

In D85095#2279476, @apazos wrote:

Can you clarify on the errors you are talking about? Are you building LLVM libc++with glibc?
I have been building LLVM libc++ with MUSl and I do not see a build issue.

this revision is not riscv32 specific. Let me know if this is ok

Fix formatting errors

In D70764#1807405, @smeenai wrote:

In D70764#1803559, @raj.khem wrote:

this is now in master, and I am seeing build failures in cross-building clang, e.g. when building clang for arm on a x86_64 host. its resorting to finding, libz from buildhost instead of target sysroot ( using --sysroot) and failing in link step. e.g.

FAILED: bin/llvm-config
...
.... -o bin/llvm-config -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a /usr/lib/libz.so -lrt -ldl -ltinfo -lm lib/libLLVMDemangle.a
...

aarch64-yoe-linux-musl/aarch64-yoe-linux-musl-ld: /usr/lib/libz.so: error adding symbols: file in wrong format
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

you can see that its adding /usr/lib/libz.so to linker cmdline while cross linking.

Have you set CMAKE_SYSROOT appropriately?

this is now in master, and I am seeing build failures in cross-building clang, e.g. when building clang for arm on a x86_64 host. its resorting to finding, libz from buildhost instead of target sysroot ( using --sysroot) and failing in link step. e.g.

LGTM now. I am testing it in yocto multilib SDK builds.

@AndreyChurbanov Can you push/commit this patch as well. As I dont have commit privs.

In D57529#1697029, @ostannard wrote:

A patch adding the same functionality was added back in May: D61719, rL360381.

Reviewers tend to assume that patch authors have commit access, if you don't then just say so when the patch is accepted and the reviewer will commit it for you.

@rengolin who can help committing this patch ?

somehow when doing stage2 build, it is stubborn and does not respect any of PYTHON_EXECUTABLE. PYTHON_LIBRARY or PYTHON_INCLUDE_DIR that were passed with -D on cmake invocation even after they are added to -DDCLANG_BOOTSTRAP_PASSTHROUGH list. llvm finds its own python during stage2. in stage1 it respects the above settings.

In D65699#1662915, @dalias wrote:

That's a separate issue of clang having a slight types-ABI mismatch with some 32-bit archs whose original ABIs used long instead of int for wchar_t. The wrong header order makes it quickly apparent, but these are independent; wrong header order is still wrong and will break (other) things even without this type mismatch. Backport of the fix would be much appreciated.

one issue I now see is that when we have some thing like

Can we bring this to 9.x release branch as well please ?

In D65572#1614003, @compnerd wrote:

-ldl doesn't work on all platforms (e.g. android, FreeBSD, etc). -lpthread is wrong - if you want to add that, I think that we need to improve the -thread-model flag in clang first (it currently just always passes posix, which is ignored; but would identify the threading model). -lpthread is wrong - consider building on Solaris with Solaris threads rather than POSIX threads, or on Windows with the Win32 threading. This really is inline with the work that needs to be finished up with having library link dependencies for static libraries (i.e. #pragma comment(lib, …)).

In D65572#1610169, @rengolin wrote:

This is a tricky one which may vary depending on the libraries available on different systems. Which toolchain is this? Can you add more context?

Can someone with commit access push this for me please ?

Can this be backported to release_60 branch too please ?

This version works across all compilers.

@EricWF yes please. I don't have push privileges.

There is a proposed fix for glibc's assert here

@EricWF you are right. I have made the changes accordingly. This patch can be ignored.

@EricWF it builds fine on archlinux with this change and tests show no regressions. archlinux install right now has glibc 2.25, the xlocale.h change is committed to upcoming glibc 2.26 and newer. So I suppose it was not required all along on glibc based builds. Given this I fairly confident that we should be good with backward compatibility.

I agree clang should not emit __ARM_FEATURE_CRC32 when -march is armv8-a it can generate it if we have march set to armv8-a+crc, there is another issue with compiler-rt build when clang is configured for multiple backends, COMPILER_RT_HAS_MCRC_FLAG macros gets defined even for x86_64 so we actually need to check for target as well.
something like below

I agree its a clang driver problem and I did mention that in my earlier comment, this is a workaround that helps until clang is fixed and its limited to this one file.

I think this one is better because the other patch you point to is double including locale.h which is redundant so I suggests to apply this patch

libcxx still has problem compiling on musl/aarch64 though. I fixed it with this patch

I think my problem was that while compiling libcxxabi, it wants to peek into libcxx headers but then libcxxabi cmake infra doesnt have the musl support like libcxx. So Now I solved it by adding -D_LIBCPP_HAS_MUSL_LIBC to CXXFLAGS.

3.8 has it in there. So may be this is just not required. I will add
-DLIBCXX_HAS_MUSL_LIBC=ON to Cmake and see what comes out

@bcraig, right, check for GLIBC can be moved after including features.h.
https://chromium.googlesource.com/native_client/pnacl-libcxx/+/master%5E!/
seems to add needed tweaks which can be enabled by passing -Dmusl in CFLAGS
may be it can be backported to 3.8 branch

OK can you push this too for me please ?

In D12777#243764, @t.p.northover wrote:

Is there a bug against GAS for this? These register aliases should probably be supported there (they're mentioned in the AAPCS).

Renato, can you take a look at this for me please ?

not needed. Fixed elsewhere

Hi Renato,

Can we pull it into branch_37 as well please ?

this has been fixed by

Create a test-case as suggested