Exceptions in ARM

[Johannes Pfau]

Am Sun, 02 Mar 2014 11:20:53 +0000
schrieb "Timo Sintonen" <t.sintonen at luukku.com>:

> On Saturday, 1 March 2014 at 12:53:14 UTC, Johannes Pfau wrote:
> 
> >
> > However, someone also had this problem on this german site:
> > http://www.mikrocontroller.net/topic/312956
> >
> > and the solution was that -mcpu alone was not good enough, he 
> > had to specify -march flags as well so please double-check your 
> > flags.
> > It's possible that binutils doesn't work properly with -mcpu so 
> > I'd do this:
> >
> > -march=armv7e-m -mcpu=cortex-m4 -mthumb -mtune=cortex-m4
> >
> > Or better at configure time:
> >
> > --with-arch=armv7e-m --with-cpu=cortex-m4 --with-mode=thumb 
> > --with-tune=cortex-m4
> >
> I read somewhere that -march is ignored when the more specific 
> -mcpu is present. On the other hand, ld has no cpu option, only 
> --architecture. That did not have any effect.
> 
> A little background: I have the main makefile and all definitions 
> in toplevel directory. Libraries and projects are in subdirs. Any 
> subdir makefile includes settings from topdir. In topdir I just 
> give export projectdir=xxx and then run make. Any project in any 
> language is run from the same makefile with the same settings. I 
> use separate compiling and pass myself options to gcc, as and ld. 
> A reduced version of this toolset is in the minlibd repo in tools 
> directory.

OK, but at least for the initial problem the question is how did you
build _libgcc_. I guess it was build as part of the normal
gcc ./configure & make & make install process. 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)

> 
> I decided to rebuild all my apps and libs. Now I have lots of blx 
> instructions in my code. So this is not related to exceptions. I 
> just triggered this when playing with deh.d.
> 
> I have not been able to confirm this, but this may be something 
> like when linking libraries that have unresolved symbols. If the 
> symbol is already available, the call is bl, but if the symbol 
> will be resolved from a later library, the call will be blx. 
> Libgcc is always the last so any call to its functions will be 
> blx.

Sounds strange, I don't think we could cause this in the gdc frontend.

I guess binutils generates blx if thumb code calls arm code or the
other way round. So I'd verify which libraries are really picked up by
ld (ld --verbose) then check if the entry points are in thumb or arm
mode:
http://stackoverflow.com/a/15931232

This sounds a lot as if calls to the same library/object file generate
bl instructions as the code is in the same mode, but functions in
external libraries are in a different mode and therefore generate blx.

> 
> When I compile my c only project, I will not get these calls. I 
> have compared the object list files but I can not find any 
> meaningful difference. Could it be possible that gdc generated 
> asm files have some attribute/directive/segment name/whatever 
> that changes the behavior in ld. Obviously there are more 
> segments in d executable, like unwind and debug info. What is the 
> thing that makes it different for ld?
> 

I'm not sure but I still don't think we could cause this. This
low-level stuff is usually part of the backend, the frontend doesn't
know much about thumb/arm.

Did you use the same gcc which was compiled with your gdc or did you
use a gcc from a different toolchain?
In either case I probably need a reduced test case, otherwise I'm just
guessing here ;-)