Exceptions in ARM

[Timo Sintonen]

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.