Am Sun, 02 Mar 2014 18:33:00 +0000 schrieb "Timo Sintonen" <t.sinto...@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.
