Am Sun, 02 Mar 2014 11:20:53 +0000 schrieb "Timo Sintonen" <t.sinto...@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 ;-)
