On Friday, 7 March 2014 at 18:41:35 UTC, Johannes Pfau wrote:
> To make sure that libgcc
> is built correctly for Cortex-M4 you have to specify
> "--with-arch=armv7e-m --with-cpu=cortex-m4 --with-mode=thumb
> --with-tune=" when configuring gcc/gdc.
>
Gcc build fails with these. It will take time to check them
one by one. Also enable/disable-multilib may affect to this.
It seems that the gcc compilation fails with any of these. These
flags do set the features of the compiler which in turn have
effect to the libraries it builds. These do not set the libgcc
build process and I get similar errors than Mike reported a while
ago. The reason is that the build process still try to make arm
mode libraries even when the compiler is thumb only.
Multilib is indeed special. AFAIK it's not possible to change
multilib
flags without changing some file in gcc (gcc/config/t-arm or
something
like that).
It has been my plan to investigate the library build process this
weekend
I'd like to know the reason as well, but I think I really need
a small
test case to continue looking into this. Could you upload your
toolchain binaries somewhere?
You seem to be right that binutils doesn't have an architecture
flag and
therefore the linker can't even know you're targeting Cortex-M4.
In my simple tests ld does really only use blx for arm->thumb /
thumb->arm calls. In all other cases it uses bl. And it's
indeed the
linker making this decision, the compiler always emits 'bl'.
Would be
great if you could confirm if it's a linker issue in your case
as well.
I was getting different object files from the same sources with
different versions of the compiler. I tried to find what was the
difference between those files. An oo language naturally makes a
little bit different object file than pure c. There was something
that made ld think the files are different and needed the
interworking call. I just could not find what was the flag or
attribute or section that made ld to think so.
As I told, then I updated everything to latest head versions and
I think I am now where I was before. I do not have the original
binaries any more. Binutils 2-23 and gcc/gdc heads between mid of
january to mid of february at least caused the problem. There
still is some blx instructions but I think they have always been
there. I just have not needed those functions before I started
with exceptions.
The linking process seems to be controlled by those arm
attributes. I did not know readelf can also read .o files. It
lists attributes and all kind of info much better than objdump.
Next I will investigate my files with this and try to find out
how to affect to libgcc generation.
