Forcing default target, linker, includes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Forcing default target, linker, includes

Kristof Beyls via cfe-dev
I’ve built clang, compiler_rt, and lld on Linux from LLVM master as of last night targeting MIPS like so:

cmake \
        -G Ninja \
        $CMHPROJECTS/llvm-project/llvm \
        -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld" \
        -DCMAKE_INSTALL_PREFIX="/opt/llvm-mips" \
        -DLLVM_TARGETS_TO_BUILD="Mips"

ninja -j8 -k8

(A couple things fail to link but clang, lld, etc. do get built.)

Unfortunately the built clang does two things I don’t want: It looks in my Linux system’s / for headers even when I specify -isysroot and it uses my Linux system’s ld instead of the built lld even when I specify -fuse-ld=lld.

Are there CMake flags that I can use to force the built clang to only ever use headers from the provided sysroot? (And of course, I’d love the same for forcing lld to only look in sysroot for libraries.) How about CMake flags to force the built clang to only use its paired lld?

I also have to specify a number of options to get the (IRIX MIPS IV n64 ABI) code generation I desire; I’m compiling hello.c in my LLVM build directory with:

./bin/clang -g --std=c99 -D_LANGUAGE_C=1 -D__sgi=1 -D_SGIAPI=1 -D_SGI_SOURCE=1 -D_MIPSABI_SOURCE=1 --target=mips-sgi-irix -march=mips4 -m64 -isysroot $IRIXSDK -isystem $IRIXSDK/usr/include -c hello.c

Obviously the target tuple mips-sgi-irix isn’t supported, it does at least result in MIPS codegen and the rest winds up getting me MIPS IV n64. If I eventually add support for the sgi-irix part of the target tuple I know I can easily make it imply the preprocessor macros, but is that also necessary to force the use of the MIPS n64 ABI? Or is there some other way to select which MIPS ABI that I get? And is there a CMake option I can use to make all of that the default for the built clang?

  — Chris

Sent from my iPad

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Forcing default target, linker, includes

Kristof Beyls via cfe-dev

I suspect most of your issues are related to Clang not understanding the triple you want, and falling back to host-related defaults.

You can tell cmake `-DLLVM_DEFAULT_TARGET_TRIPLE=mips-sgi-irix` so at least that part would be your default.  And once you define the triple components, you can set up a ToolChain in the driver that can probably set up most or all of the rest of that stuff.

HTH,

--paulr

 

From: cfe-dev <[hidden email]> On Behalf Of Chris Hanson via cfe-dev
Sent: Wednesday, November 6, 2019 3:11 PM
To: [hidden email]
Subject: [cfe-dev] Forcing default target, linker, includes

 

I’ve built clang, compiler_rt, and lld on Linux from LLVM master as of last night targeting MIPS like so:

 

cmake \

        -G Ninja \

        $CMHPROJECTS/llvm-project/llvm \

        -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld" \

        -DCMAKE_INSTALL_PREFIX="/opt/llvm-mips" \

        -DLLVM_TARGETS_TO_BUILD="Mips"

 

ninja -j8 -k8

 

(A couple things fail to link but clang, lld, etc. do get built.)

 

Unfortunately the built clang does two things I don’t want: It looks in my Linux system’s / for headers even when I specify -isysroot and it uses my Linux system’s ld instead of the built lld even when I specify -fuse-ld=lld.

 

Are there CMake flags that I can use to force the built clang to only ever use headers from the provided sysroot? (And of course, I’d love the same for forcing lld to only look in sysroot for libraries.) How about CMake flags to force the built clang to only use its paired lld?

 

I also have to specify a number of options to get the (IRIX MIPS IV n64 ABI) code generation I desire; I’m compiling hello.c in my LLVM build directory with:

 

./bin/clang -g --std=c99 -D_LANGUAGE_C=1 -D__sgi=1 -D_SGIAPI=1 -D_SGI_SOURCE=1 -D_MIPSABI_SOURCE=1 --target=mips-sgi-irix -march=mips4 -m64 -isysroot $IRIXSDK -isystem $IRIXSDK/usr/include -c hello.c

 

Obviously the target tuple mips-sgi-irix isn’t supported, it does at least result in MIPS codegen and the rest winds up getting me MIPS IV n64. If I eventually add support for the sgi-irix part of the target tuple I know I can easily make it imply the preprocessor macros, but is that also necessary to force the use of the MIPS n64 ABI? Or is there some other way to select which MIPS ABI that I get? And is there a CMake option I can use to make all of that the default for the built clang?

 

  — Chris

 

Sent from my iPad


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Forcing default target, linker, includes

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev
There's CLANG_DEFAULT_LINKER to set the default linker. There are other similar flags like CLANG_DEFAULT_OBJCOPY, CLANG_DEFAULT_CXX_STDLIB, CLANG_DEFAULT_RTLIB.

One issue I ran into is these settings are currently global and not per-target. This is an issue e.g. on macOS where using CLANG_DEFAULT_LINKER=lld makes even the Darwin target use lld which is a problem. This is something we should address by either this setting a per-target or change Darwin to always use system linker and ignore that option.

There isn't CLANG_DEFAULT_SYSROOT right now. We could probably introduce it but it'd have the same problem as CLANG_DEFAULT_LINKER where a single option isn't going to work for all targets.

One thing we wanted to do for Fuchsia is implementing support for finding sysroot in tooldir/sys-root/<target> which is already supported by GCC.

On Wed, Nov 6, 2019 at 12:11 PM Chris Hanson via cfe-dev <[hidden email]> wrote:
I’ve built clang, compiler_rt, and lld on Linux from LLVM master as of last night targeting MIPS like so:

cmake \
        -G Ninja \
        $CMHPROJECTS/llvm-project/llvm \
        -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld" \
        -DCMAKE_INSTALL_PREFIX="/opt/llvm-mips" \
        -DLLVM_TARGETS_TO_BUILD="Mips"

ninja -j8 -k8

(A couple things fail to link but clang, lld, etc. do get built.)

Unfortunately the built clang does two things I don’t want: It looks in my Linux system’s / for headers even when I specify -isysroot and it uses my Linux system’s ld instead of the built lld even when I specify -fuse-ld=lld.

Are there CMake flags that I can use to force the built clang to only ever use headers from the provided sysroot? (And of course, I’d love the same for forcing lld to only look in sysroot for libraries.) How about CMake flags to force the built clang to only use its paired lld?

I also have to specify a number of options to get the (IRIX MIPS IV n64 ABI) code generation I desire; I’m compiling hello.c in my LLVM build directory with:

./bin/clang -g --std=c99 -D_LANGUAGE_C=1 -D__sgi=1 -D_SGIAPI=1 -D_SGI_SOURCE=1 -D_MIPSABI_SOURCE=1 --target=mips-sgi-irix -march=mips4 -m64 -isysroot $IRIXSDK -isystem $IRIXSDK/usr/include -c hello.c

Obviously the target tuple mips-sgi-irix isn’t supported, it does at least result in MIPS codegen and the rest winds up getting me MIPS IV n64. If I eventually add support for the sgi-irix part of the target tuple I know I can easily make it imply the preprocessor macros, but is that also necessary to force the use of the MIPS n64 ABI? Or is there some other way to select which MIPS ABI that I get? And is there a CMake option I can use to make all of that the default for the built clang?

  — Chris

Sent from my iPad
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Forcing default target, linker, includes

Kristof Beyls via cfe-dev
Thanks for the help! I feel like I’m getting quite a bit closer with only a little bit of hacking.

This is now how I’m configuring LLVM/clang/lld master as of earlier this afternoon, it builds just fine (using clang 9 from the web site on Ubuntu 19.04):

in $LLVM/build
$ cmake \
        -G Ninja \
        "${PROJECT_DIR}/llvm-project/llvm" \
        -DCMAKE_INSTALL_PREFIX="/opt/llvm-mips" \
        -DLLVM_DEFAULT_TARGET_TRIPLE="mips-sgi-irix" \
        -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld;libunwind" \
        -DLLVM_TARGETS_TO_BUILD="Mips" \
        -DCLANG_DEFAULT_OBJCOPY="llvm-objcopy" \
        -DCLANG_DEFAULT_LINKER="lld" \
        -DCLANG_DEFAULT_RTLIB="compiler-rt" \
        -DCLANG_DEFAULT_UNWINDLIB="libunwind"

(Incidentally, I found a single use of CLANG_DEFAULT_RTLIBS in the CMake files, I assumed it shouldn’t be plural  since there were no other uses, so I fixed it locally.)

I also set up a new Irix toolchain which has required only tiny initial modifications:
  • Cloned Driver/ToolChains/MipsLinux.{cpp,h} to Irix.{cpp,h}, renaming the class to just Irix (yeah it should be based on Generic_ELF but this was expedient)
    • Added an override of getDefaultLinker() to return “ld.lld”
  • Added target triple resolution for the new Irix toolchain to Basic/Targets.cpp
  • Cloned SolarisTargetInfo to IrixTargetInfo in Basic/Targets/OSTargets.h
    • Adding __sgi as a predefined macro to it
  • Made Driver.cpp instantiate the toolchain for an Irix target triple
  • Added ToolChains/MipsLinux.cpp to Driver/CMakeLists.txt

All of this lets me compile for Irix using a command like the following:

in $LLVM/build
$ ./bin/clang -g -D_LANGUAGE_C=1 \
    -D__sgi=1 -D_SGIAPI=1 -D_SGI_SOURCE=1 -D_MIPSABI_SOURCE=1 \
    --target=mips-sgi-irix march=mips4 -m64 -isysroot $IRIXSDK \
    -c ../test/hello.c

The .o this produces is recognized reasonably by file:

in $LLVM/build
$ file hello.
hello.o: ELF 64-bit MSB relocatable, MIPS, MIPS-IV version 1 (SYSV), with debug_info, not stripped

Unfortunately actually trying to produce an executable doesn’t work so well yet. It does use lld, but it tries to resolve a symbol inside the Irix libc.so which will actually be filled in by the runtime loader (rld). This combined compilation and linking line:

in $LLVM/build
$ bin/clang -v -Wl,-t -Wl,--verbose \
    -nostdlib -g -D_LANGUAGE_C=1 \
    -D__sgi=1 -D_SGIAPI=1 -D_SGI_SOURCE=1 -D_MIPSABI_SOURCE=1 \
    --target=mips-sgi-irix -march=mips4 -m64 -isysroot $IRIXSDK \
    $IRIXSDK/usr/lib64/mips4/libc.so \
    $IRIXSDK/usr/lib64/mips4/crt1.o \
    -o hello ../test/hello.c

produces this output (lightly edited for clarity, i.e. trimming paths to $LLVM and $IRIXSDK):

clang version 10.0.0 (llvm-project.git f67aec686b01518c5cf9842ad22d7113b2d50955)

Target: mips64-sgi-irix

Thread model: posix

InstalledDir: $LLVM/build/./bin

 "$LLVM/build/llvm/bin/clang-10" -cc1 -triple mips64-sgi-irix -emit-obj -mrelax-all -disable-free -main-file-name hello.c -mrelocation-model pic -pic-level 1 -mthread-model posix -mframe-pointer=all -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -target-cpu mips4 -target-feature -noabicalls -target-abi n64 -mfloat-abi hard -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -v -resource-dir $LLVM/build/llvm/lib/clang/10.0.0 -isysroot $IRIXSDK -D _LANGUAGE_C=1 -D __sgi=1 -D _SGIAPI=1 -D _SGI_SOURCE=1 -D _MIPSABI_SOURCE=1 -internal-isystem $LLVM/build/llvm/lib/clang/10.0.0/include -fdebug-compilation-dir $LLVM/build -ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fdiagnostics-show-option -faddrsig -o /tmp/hello-190bff.o -x c ../test/hello.c

clang -cc1 version 10.0.0 based upon LLVM 10.0.0svn default target mips-sgi-irix

ignoring nonexistent directory "$IRIXSDK/usr/local/include"

ignoring duplicate directory "$LLVM/build/llvm/lib/clang/10.0.0/include"

#include "..." search starts here:

#include <...> search starts here:

 $LLVM/build/llvm/lib/clang/10.0.0/include

 $IRIXSDK/usr/include

End of search list.

 "$LLVM/build/./bin/ld.lld" -z relro --eh-frame-hdr -m elf64btsmip -dynamic-linker /lib64/ld.so.1 -o hello -L/usr/lib64 -t --verbose $IRIXSDK/usr/lib64/mips4/libc.so $IRIXSDK/usr/lib64/mips4/crt1.o /tmp/hello-190bff.o

ld.lld: $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: $IRIXSDK/usr/lib64/mips4/crt1.o

ld.lld: /tmp/hello-190bff.o

$IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.data' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.got' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.sbss' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.srdata' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.sdata' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.lit8' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.lit4' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

ld.lld: warning: found local symbol '.bss' in global part of symbol table in file $IRIXSDK/usr/lib64/mips4/libc.so

$IRIXSDK/usr/lib64/mips4/crt1.o

/tmp/hello-190bff.o

ld.lld: error: $IRIXSDK/usr/lib64/mips4/libc.so: undefined reference to _rld_new_interface

clang-10: error: linker command failed with exit code 1 (use -v to see invocation)


Why is clang cc1 saying $IRIXSDK/usr/include doesn’t exist, when it actually does? (Just to reiterate, I’m using $IRIXSDK in this email for concision, it actually gives the full path—which “ls” lists the contents of just fine.)

Why is lld trying to resolve an undefined reference within a shared library, and what can I do about it? (The _rld_new_interface symbol is filled in by rld when it loads libc, there’s no need for it to be resolved against anything.) I’m not super familiar with ELF unlike Mach-O so I’m kind of surprised by this.

Is it related to the warnings about local symbols in global parts of the symbol table in libc.so? Is there any way to suppress those too, or to have lld interpret them “properly” (as SGI intended in Irix 6.5.30, irrespective of what’s proper today)?

  — Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Forcing default target, linker, includes

Kristof Beyls via cfe-dev
Hi,

On Sun, Nov 10, 2019 at 2:27 AM Chris Hanson via cfe-dev
<[hidden email]> wrote:
>
> ignoring nonexistent directory "$IRIXSDK/usr/local/include"

[...]

> Why is clang cc1 saying $IRIXSDK/usr/include doesn’t exist, when it actually does?
> (Just to reiterate, I’m using $IRIXSDK in this email for concision, it actually gives
> the full path—which “ls” lists the contents of just fine.)

The message is about "$IRIXSDK/usr/local/include" but you say that
"$IRIXSDK/usr/include" exists.

> Why is lld trying to resolve an undefined reference within a shared library, and what
> can I do about it? (The _rld_new_interface symbol is filled in by rld when it loads libc,
> there’s no need for it to be resolved against anything.) I’m not super familiar with ELF
> unlike Mach-O so I’m kind of surprised by this.

LLD has many MIPS specific piece of code because this architecture
rather differs from other ones. But if you take a look at the code of
the GNU BFD linker you see that even MIPS-dedicated elfxx-mips.c file
has a lot of SGI-specific code because SGI differs from "general"
MIPS.

In particular, there is the following piece of code in the
_bfd_mips_elf_add_symbol_hook:
[[
  if (SGI_COMPAT (abfd)
      && (abfd->flags & DYNAMIC) != 0
      && strcmp (*namep, "_rld_new_interface") == 0)
    {
      /* Skip IRIX5 rld entry name.  */
      *namep = NULL;
      return TRUE;
    }
]]

In LLD you can try to handle that in the addReservedSymbols() function.

> Is it related to the warnings about local symbols in global parts of the symbol table in libc.so?
> Is there any way to suppress those too, or to have lld interpret them “properly” (as SGI intended
> in Irix 6.5.30, irrespective of what’s proper today)?

The error above is not related to these warnings. It looks like SGI
libraries violate ELF rule that all local symbols precede weak or
global symbols in each symbol table, and an index of first non-local
symbol is stored to sh_info. LLD checks this in the
SharedFile::parse() method.

--
Simon Atanasyan
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Forcing default target, linker, includes

Kristof Beyls via cfe-dev
On Nov 9, 2019, at 10:39 PM, Simon Atanasyan <[hidden email]> wrote:
>
> The message is about "$IRIXSDK/usr/local/include" but you say that
> "$IRIXSDK/usr/include" exists.

Doh! Thanks for catching that! I don’t know why my eyes just skipped right over the “local” there…

> In LLD you can try to handle that in the addReservedSymbols() function.
>
>> Is it related to the warnings about local symbols in global parts of the symbol table in libc.so?
>> Is there any way to suppress those too, or to have lld interpret them “properly” (as SGI intended
>> in Irix 6.5.30, irrespective of what’s proper today)?
>
> The error above is not related to these warnings. It looks like SGI
> libraries violate ELF rule that all local symbols precede weak or
> global symbols in each symbol table, and an index of first non-local
> symbol is stored to sh_info. LLD checks this in the
> SharedFile::parse() method.

Thanks for the explanations! I’ll see what I can do with this new information today. :)

  -- Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev