llvm dev - Jul 2012 - [LLVMdev] Setting up a cross-compiler for cortex-m3

On 22 July 2012 22:03, salvatore benedetto
<salvatore.benedetto at gmail.com> wrote:
> While we are at it, if a new comer would like to understand where
everything
> takes place, where should he look?
>
> I did a grep in the source and eventually ended up in
clang/something/driver.
That's pretty much it: clang/lib/Driver

http://clang.llvm.org/doxygen/dir_20b6fcdbe5e465b3389293c5a4a7422f.html

However, don't ever assume that that code is correct, or good. It's a
big mess and should be refactored to avoid the ridiculous command line
you had to use, when a simple "-mcpu=cortex-m3" should suffice.

-- 
cheers,
--renato

http://systemcall.org/

On Sun, Jul 22, 2012 at 11:12 PM, Renato Golin <rengolin at
systemcall.org> wrote:
> On 22 July 2012 22:03, salvatore benedetto
> <salvatore.benedetto at gmail.com> wrote:
>> While we are at it, if a new comer would like to understand where
everything
>> takes place, where should he look?
>>
>> I did a grep in the source and eventually ended up in
clang/something/driver.
>
> That's pretty much it: clang/lib/Driver
>
> http://clang.llvm.org/doxygen/dir_20b6fcdbe5e465b3389293c5a4a7422f.html
>
> However, don't ever assume that that code is correct, or good. It's
a
> big mess and should be refactored to avoid the ridiculous command line
> you had to use, when a simple "-mcpu=cortex-m3" should suffice.
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
It also look like I need all those options when linking, otherwise the
system ld is used
which targets my host architecture.

Giving those flags it get the correct linker but another problem came up...

../CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-linux-gnueabi/bin/ld:
error:
/home/emitrax/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/thumb2/usr/lib/libc.a(dso_handle.o):
Conflicting architecture profiles A/M

and so on for many other symbols.

../CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/libc/thumb2/usr/lib/libc.a
| grep dso_handle.o -A 10
File:
/home/emitrax/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi/libc/thumb2/usr/lib/libc.a(dso_handle.o)
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed

while

$ arm-none-linux-gnueabi-readelf -A system.cpp.o
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "Cortex-M3"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Microcontroller
  Tag_THUMB_ISA_use: Thumb-2
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_DIV_use: Not allowed

I'm not sure what is going on here. Different naming convention?

The other problem I have to figure out is why it links with libc in
the first place, but I have
an idea.

Thanks again for all your support.

S.

> I'm not sure what is going on here. Different naming convention?
Different profile. You have to link with stuff compiled for v7M

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Mon, Jul 23, 2012 at 9:51 AM, salvatore benedetto
<salvatore.benedetto at gmail.com> wrote:
>
> The other problem I have to figure out is why it links with libc in
> the first place, but I have
> an idea.
Actually I dont.

I used the -Wl,-v to see the flags used.

/home/emitrax/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-linux-gnueabi/bin/ld
--sysroot=/home/emitrax/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/thumb2
-Bstatic -dynamic-linker /lib/ld-linux.so.3 .....  -lstdc++ -lm
--start-group -lgcc -lgcc_eh -lc --end-group -T stm32f103rbt6.ld

apart from the fact that I don't understand why it reference the host
dynamic linker.
I removed all this flags

-lm --start-group -lgcc -lgcc_eh -lc --end-group

and it compiled fine.

Please note, that I'm using a list container from the STL provided with
libcxx.

On GCC I had the same problem, but when removing those flags it didn't
compile as symbols
in the libc were needed. This seem not to be the case with clang.

Now I need to understand why those flags are added in the first place.

S.