ARM cross fails after recent changes to clang in branch release_30

Clang Frontend
1

Hi,

On Nov. 7, one of the 30 commits to the clang release_30 branch
breaks my ARM cross compilers: when configuring with
  --with-c-include-dirs=some/path
this path does not get added to the list of include dirs anymore.
Reverting the patches back to the following commit fixes the problem:

commit 7733429d361ec671ae3bfbb8c3cf33c2078d0fc1
Author: Bill Wendling <isanbard@gmail.com>
https://llvm.org/svn/llvm-project/cfe/branches/release_30@143432

Sebastian

2

Hi,

On Nov. 7, one of the 30 commits to the clang release_30 branch
breaks my ARM cross compilers: when configuring with
–with-c-include-dirs=some/path
this path does not get added to the list of include dirs anymore.
Reverting the patches back to the following commit fixes the problem:

Can you give any more details? Can you show the run of clang with ‘-v’ passed where the headers fail to be found, and the paths you passed to that configure?

This isn’t something obvious – we are still pulling in the configure time C_INCLUDE_DIRS list into the header search, so something else is likely going wrong.

3

Can you give any more details? Can you show the run of clang with '-v'
passed where the headers fail to be found, and the paths you passed to that
configure?

With clang on the release_30 branch configured with:

../configure --target=arm-none-linux-gnueabi --enable-targets=arm
--with-c-include-dirs=/y/arm-none-linux-gnueabi/libc/usr/include:/y/lib/gcc/arm-none-linux-gnueabi/4.5.2/include
--with-cxx-include-root=/y/arm-none-linux-gnueabi/include/c++/4.5.2
--with-cxx-include-arch=arm-none-linux-gnueabi

# cd /x/build/Debug+Asserts/bin
# clang -v foo.c
[...]
#include "..." search starts here:
End of search list.
/x/foo.c:1:10: fatal error: 'stdio.h' file not found
#include "stdio.h"
         ^
1 error generated.

After reverting the 30 patches and configuring with the same flags,
I get this:

# cd /x/build/Debug+Asserts/bin
# clang -v foo.c
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/x/build/Debug+Asserts/bin/../lib/clang/3.0/include
/y/arm-none-linux-gnueabi/libc/usr/include
/y/lib/gcc/arm-none-linux-gnueabi/4.5.2/include
End of search list.
[...]
This then continues to the ARM assembler and finishes compilation fine.

This isn't something obvious -- we are still pulling in the configure time
C_INCLUDE_DIRS list into the header search, so something else is likely
going wrong.

Yes, I put a breakpoint on the use of C_INCLUDE_DIRS and it never
stopped when I run clang as a driver or when running clang as cc1
compiler.

Let me know how I can continue to help to fix this.

Thanks,
Sebastian

4

clang -v foo.c

[…]

Eeep! I asked for the output because… well, I need the output! ;] You’ve snipped the really important part here: the paths it didn’t find but tried to find, the target it decided to use, the CC1 invocation, etc. =D

Can i have the full output?

5

# ./clang -v /x/foo.c
clang version 3.0 (/x/llvm/tools/clang 474341250c818952c314e539f0f53199080a5faf)
Target: arm-none-linux-gnueabi
Thread model: posix
"/x/build/Debug+Asserts/bin/clang" -cc1 -triple
armv4t-none-linux-gnueabi -S -disable-free -main-file-name foo.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-target-abi aapcs-linux -target-cpu arm7tdmi -mfloat-abi soft
-target-feature +soft-float-abi -target-linker-version 2.16.91.0.5
-momit-leaf-frame-pointer -v -resource-dir
/x/build/Debug+Asserts/bin/../lib/clang/3.0 -fmodule-cache-path
/var/tmp/clang-module-cache -ferror-limit 19 -fmessage-length 136
-fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/foo-Axc7do.s -x c /x/foo.c
clang -cc1 version 3.0 based upon llvm 3.0 default target arm-none-linux-gnueabi
#include "..." search starts here:
End of search list.
/x/foo.c:1:10: fatal error: 'stdio.h' file not found
#include "stdio.h"
         ^
1 error generated.

Sebastian

6

Hi,

Cross compilers using include files different than hosts' system include files
on Linux started failing from the moment we added the case llvm::Triple::Linux
to the following switch:

void InitHeaderSearch::AddDefaultIncludePaths(const LangOptions &Lang,
                                               const llvm::Triple &triple,
                                             const HeaderSearchOptions
&HSOpts) {
+ // NB: This code path is going away. All of the logic is moving into the
+ // driver which has the information necessary to do target-specific
+ // selections of default include paths. Each target which moves there will be
+ // exempted from this logic here until we can delete the entire pile of code.
+ switch (triple.getOS()) {
+ default:
+ break; // Everything else continues to use this routine's logic.