[llvm-bugs] [Bug 46330] New: clang ignores linker script option -T when cross compiling for freestanding environment

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jun 15 08:47:09 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46330

            Bug ID: 46330
           Summary: clang ignores linker script option -T when cross
                    compiling for freestanding environment
           Product: clang
           Version: 10.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: alex.bereza at huawei.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Hello,

I'm running into problems during the linking phase, when trying to
cross-compile for an aarch64 bare-metal target on a X86_64 host.

I have tried using the GNU linker and lld, which both fail, but with different
reasons. Clang either ignores the linker script that I pass via command line
option -T or it assumes that I'm trying to link an X86_64 binary, while my
target actually is aarch64.

Here is a minimal example:

main.c:

```
void bare_metal_entry(void){
        return;
}
```

linkerscript.ld:

```
ENTRY(bare_metal_entry)

SECTIONS {
    .text : { *(.text*) }
    .rodata : { *(.rodata*) }
    .data : { *(.data*) }
    .bss : { *(.bss COMMON) }
}
```

Compile command:

```
clang --target=aarch64-none-elf -ffreestanding -nostdlib -o main.c.obj -c
main.c
``` 

When linking with the command

```
/home/alex/opt/lld/bin/clang --target=aarch64-none-elf -ffreestanding -nostdlib
main.c.obj -T linkerscript.ld
```

I get:

```
/usr/bin/ld: unknown architecture of input file `main.c.obj' is incompatible
with i386:x86-64 output
collect2: error: ld returned 1 exit status
clang-11: error: linker (via gcc) command failed with exit code 1 (use -v to
see invocation)
```

When using lld via -fuse-ld=lld the situation is the same, the error message is
just slightly different:

```
ld.lld: error: main.c.obj is incompatible with elf_x86_64
collect2: error: ld returned 1 exit status
clang-11: error: linker (via gcc) command failed with exit code 1 (use -v to
see invocation)
```

I don't have an aarch64-none-elf-ld on my PATH. I realized that the behavior
changes when the target triplet matches the one of a GNU linker which I do have
on my PATH. I'm using Ubuntu 20.04 LTS and have installed aarch64-linux-gnu-ld
on my system from the corresponding package.

When linking with the command

```
/home/alex/opt/lld/bin/clang --target=aarch64-linux-gnu -ffreestanding
-nostdlib main.c.obj -T linkerscript.ld
```

I get:

```
clang-11: warning: argument unused during compilation: '-T linkerscript.ld'
[-Wunused-command-line-argument]
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00000000004000b0
```

The linking succeeds, but the linked binary is not what I expect, because as
written above, the linker script is ignored.

When bypassin clang invocation and linking directly via

```
aarch64-linux-gnu-ld main.c.obj -T linkerscript.ld
```

or

```
ld.lld main.c.obj -T linkerscript.ld
```

the linking succeeds and the linker script is respected.


I maybe I am getting something wrong regarding the target triplet. If yes,
could you please point me to the relevant documentation? Independent from that
I think the fact the linker script is ignored with the output 


```
clang-11: warning: argument unused during compilation: '-T linkerscript.ld'
[-Wunused-command-line-argument]
```

might be a bug.

I tried a recent clang version that I built from upstream and clang from an
installed package. The result is the same. Here are the versions I tried:

clang version 11.0.0 (https://github.com/llvm/llvm-project.git
14c1e987546ef161769aa619bb9de21c943721ec)
clang version 10.0.0-4ubuntu1

Please let me know if this is in fact a bug or if I am doing something wrong.
Thank you.

Best regards,
Alex Bereza

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200615/d94ee4f7/attachment-0001.html>


More information about the llvm-bugs mailing list