Clang compiling needs help

Clang Frontend
1

Dear Clang Experts,

I’m a Clang user. I met some problem during using Clang. Would you please help to give any suggestion?

I’m using Clang to compile a lib. The generated lib file will be linked to other source code in other compile environment.

One target of the final image is ARM and the other is MIPS.

When compile the lib for ARM, we use the options as below:

ARCH_OPTS=-target arm-none-eabi -mcpu=arm926ej-s

LLC_ARCH_OPTS=“-mtriple armv5-none-none-eabi -mattr=+v5te”

AR=/usr/bin/ar

ARFLAGS=-rv

We got the lib successfully. But when linked to other source code in ARM, we got the error as below:

image001.png
image001.png1178×106 2.59 KB

Do you have any idea of the error “invalid call from ‘~PRE8’”? Should I make some change when compile the lib with CLANG?

When compile the lib for MIPS, we use the options as below:

ARCH_OPTS=-target mipsel

CFLAGS=-c -fno-pic -mabicalls -integrated-as

We got the lib successfully. But when linked to other source code in MIPS, we got the error as below:

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_clzsi2.o): warning: linking abicalls files with non-abicalls files

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_fixunsdfsi.o): warning: linking abicalls files with non-abicalls files

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_pack_df.o): warning: linking abicalls files with non-abicalls files

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_unpack_df.o): warning: linking abicalls files with non-abicalls files

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_fpcmp_parts_df.o): warning: linking abicalls files with non-abicalls file

s

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_ge_df.o): warning: linking abicalls files with non-abicalls files

mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib

gcc.a(_df_to_si.o): warning: linking abicalls files with non-abicalls files

make[2]: *** [/cygdrive/d/RDA/Projects/QW300/soft/build/8851m_dbs_rdamodem_qj/_d

efault_/8809/8851m_dbs_rdamodem_qj_debug.elf] Error 1

make[1]: *** [/cygdrive/d/RDA/Projects/QW300/soft/build/8851m_dbs_rdamodem_qj/_d

efault_/8809/8851m_dbs_rdamodem_qj_debug.srec] Error 2

make: *** [lod] Error 2

Do you have any idea about the warnings? How about the errors?

I’m not familiar with Clang, but if not use Clang, the linking is successful. So we hope we can get some help from you, the experts of CLANG.

Thank you in advance!

BR,

Michelle

2

That error looks like an armlink error, and there’s some documentation for it here:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0807g/dom1365073159742.html

Clang always emits objects with the PRES8 (preserves 8-byte stack alignment) and REQ8 (requires

8-byte stack alignment) attributes, so it looks like the error is coming from objects that haven’t

been built with clang (I’m guessing that’s the “other source code in ARM” you mention).

Probably you need to look these other objects and how they’re built in order to resolve this.

John

image001.png
image001.png1178×106 2.59 KB

3

The "warning: linking abicalls files with non-abicalls files" warning is almost certainly arising from a
long standing LLVM bug where all files produced from the integrated assembler for MIPS were marked
as being abicalls files. It's fixed on ToT.

In theory the produced binary should be fine, as the error is occurring from incorrect ELF header
flags. The error from 'make' may be due to treating warnings as errors.

The CFLAGS you've specified appear to be inconsistent with your mips-elf target. "-fno-pic -mabicalls"
produces position dependant code that can call position independent code. This would be for environments
such as Linux/BSDs/etc. mips-elf I expect is a bare-metal environment, so -mabicalls would not be used for
that target.

Thanks,
Simon

4

Hi John,

Thank you for feedback!

I emailed with the other objects’ vendor, they confirmed they are using ‘PRES8’ within their objects.

Do you have other suggestion?

BR,

Michelle

image001.png
image001.png1178×106 2.59 KB

5

Hi Simon,

Thank you for your feedback!

First, I delete '-fno-pic -mabicalls' options and rerun the compiling, the error result is same as before. I doubt if these options work or not.
Second, when I tried to link my lib with other projects, I can see compile option ' WITHOUT_WERROR=1' during compiling. I think that means it's not the problem of warnings became errors.

Do you have any other suggestion?

BR,
Michelle

6

Hi,

You need to use 'fno-pic -mno-abicalls -fno-integrated-as' to get the output you're
looking for I believe. It does require the use of the GNU assembler, which may require
specifying the sysroot of your gcc installation so clang finds the assembler and/or
making a symlink 'mipsel-as' to your mips-elf-as.

Hopefully that should work around the warning. I don't have any other suggestions with
the output you've posted.

-mno-abicalls with -fintegrated-as should be properly supported in the next release after 4.0.

Thanks,
Simon

7

Hi Simon,

Thank you for your feedback!

I checkout the live svn repository and build that (http://www.llvm.org/docs/GettingStarted.html).

Then use the option as below to get my object.

ARCH_OPTS=-target mipsel
CFLAGS=-c -fno-pic -mno-abicalls -integrated-as

But when linked to the mips object, the error code was still there.
Seems nothing changed.

gcc.a(_ucmpdi2.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_clzsi2.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_fixunsdfsi.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_pack_df.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_unpack_df.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_fpcmp_parts_df.o): warning: linking abicalls files with non-abicalls file
s
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_ge_df.o): warning: linking abicalls files with non-abicalls files
mips-elf-ld: /cygdrive/d/RDA/Projects/QW300/soft/env/lib/gcc/mips-elf/4.4.2//lib
gcc.a(_df_to_si.o): warning: linking abicalls files with non-abicalls files
make[2]: *** [/cygdrive/d/RDA/Projects/QW300/soft/build/8851m_dbs_rdamodem_qj/_d
efault_/8809/8851m_dbs_rdamodem_qj_debug_bin.elf] Error 1
make[1]: *** [/cygdrive/d/RDA/Projects/QW300/soft/build/8851m_dbs_rdamodem_qj/_d
efault_/8809/8851m_dbs_rdamodem_qj_debug_bin.srec] Error 2
make: *** [lod] Error 2

Any other suggestion.

BR,
Michelle

8

Can anyone please help with this?
The -mno-abicalls flag seems to still be problematic - even when using the live svn build

9

Sorry about the delay in responding.

Can you run 'readelf -h' over the files you've built and the libraries you're linking against and report back?

You're looking for which files have 'cpic' in the Flags section of the ELF header.

Thanks,
Simon

10

Hi Simon,

Thank you for your feedback.
Attached are the output according to what you said.
clang.txt is the log of the file I built, while linked.txt is the log of lib I want to link with.

BR,
Michelle

clang file.txt (3.16 KB)

linked lib.txt (1.85 MB)

11

Hi,

Those libraries and built objects look correct for noabi calls objects. I think the issue
is that clang is invoking the linker with the dynamic crt objects instead of the static crt
objects. Could you check by running the final link with -v in clang and see what directories
it points the linker to for the crt objects?

Thanks,
Simon

12

Hi Simon,

Let me explain what I did first.
I used clang to compile a lib.
Then I move this lib to another environment which is not clang.
In that environment, I linked the lib generated in clang with other object to get a final object.
The final object is running on mips platform.

I met the issue during getting the final object.

-v in the another environment is just for version.
The output is as below. But I'm afraid this is not what you need.

OTAServer@OTAServer-VM201 /cygdrive/d/RDA/Projects/QW300/soft
$ mips-elf-ld -v
GNU ld (GNU Binutils) 2.20 (Coolsand Tech v.4)

BR,
Michelle

13

Hi Simon,

Attached is the log with --verbose.

BR,
Michelle

Edit1 (287 KB)

14

Simon, just to clarify, when generating that same lib with a different compiler everything works well.
Do you still think it has something to do with dynamic vs static crt objects?

15

Hi Michelle, Alon,

I'm seeing two problems. The first is that somehow a cpic object is being pulled into the
link, but I'm not seeing where. I was suspecting crtbegin.o is at fault as none of the library
files are marked cpic, but I'm unsure that it's that object now.

The second problem (which is causing the link to fail altogether) is that the linker is
rejecting the merge of the objects produced by clang and the portions of libgcc.a. There's
a number of possible reasons for this.

It could be rejecting the link because the clang produced objects contains gnu attributes
it doesn't understand or are incompatible with the ones in libgcc.a.

A second possible reason is the supplied linker only permits xcpu objects to be linked
together, i.e. you can't link mips32r2 objects with xcpu objects.

If the xcpu is really a mips1 chip with the usual mips1 structural hazards, clang+llvm can't
target it currently, as it doesn't deal with the mips1 hazards.

Thanks,
Simon

16

Thanks Simon,

We checked with the vendor, and indeed the chip is mips1.
Does this mean we absolutely can't work with clang? Is it planned to be supported?

Thanks anyway for all your help! We really appreciate it.