Exceptions in ARM

[Johannes Pfau]

Am Sun, 02 Mar 2014 18:33:00 +0000
schrieb "Timo Sintonen" <t.sintonen at luukku.com>:

> On Sunday, 2 March 2014 at 15:36:01 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.
> >
> > (And I don't see these flags mentioned in
> > https://bitbucket.org/timosi/minlibd/src/691c76aa2b543998bb573e6ce6d96951a80817bd/README.gdc?at=default)
> >
> Gcc build fails with these. It will take time to check them one 
> by one. Also enable/disable-multilib may affect to this.

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).

> I am not saying it is a gdc bug. It may very well be a side 
> effect of a flag that is related to maybe umwinding or 
> relocation. I do have two kind of object files now in my 
> executable and I just like to know what is the difference between 
> them.

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?
 
> >
> Yes, I think blx is for this. M4 does not have arm mode and there 
> is no this instruction, so it should be a linker error if the 
> user try to mix objects with different modes.
> As I mentioned, I pass manually everything, including libgcc. 
> Nothing is picked by default. The multilib thing should be just 
> because of this. There are 4 variants of libgcc. If I pick the 
> m4-fpu library it should be already compiled with the right 
> flags. If it is not, I think that is a gcc bug.
> How can I check from the library which modes/flags is has?
> 

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.

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
4.5.3
----------
In addition to the normal rules for symbol values the following rules
shall also apply to symbols of type STT_FUNC :
If the symbol addresses a Thumb instruction, its value is the address of
the instruction with bit zero set (in a relocatable object, the section
offset with bit zero set)
----------

However, objdump is 'clever' and removes this bit m(

But with readelf:
readelf liba.o -s 
8: 00000000    28 FUNC    GLOBAL DEFAULT    1 test

readelf libt.o -s 
8: 00000001    18 FUNC    GLOBAL DEFAULT    1 test

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.