RE: [arm-gnu] sprintf issue on Cortex-M3

["James Kehl" <jamesk@xxxxxxxxxxx>]

> -----Original Message-----
> From: Freddie Chopin [mailto:freddie_chopin@xxxxx]
> Sent: Wednesday, 16 December 2009 4:35 PM
> To: unlisted-recipients
> Cc: arm-gnu@xxxxxxxxxxxxxxxx
> Subject: Re: [arm-gnu] sprintf issue on Cortex-M3
> 
> James Kehl pisze:
> > I remember hearing that later ARMs got really picky about keeping
the
> > stack aligned, and that failure to do so would cause weird problems
with
> > 64-bit vars (like doubles) - especially with odd call chains and
> > interrupts.
> 
> I don't think this is Cortex-M3-specific, but I cannot try on ARM7 - I
> only got LPC2103 right now, and sprintf() won't fit in it...
> 
> > Is it possible that --gc-sections is affecting the start address of
your
> > stack?
> 
> I've just checked, and in both cases the stack is at least word
aligned
> (without --gc-sections [when sprintf fails] it is even quad-word
> aligned), so I don't think that's the issue here.
> 

The quad-alignment was what I was thinking about.

According to ARM AAPCS:
"5.2.1.2 Stack constraints at a public interface
The stack must also conform to the following constraint at a public
interface:
  SP mod 8 = 0. The stack must be double-word aligned."

It seems a little odd that sprint would *fail* when the stack was more
highly aligned; is your startup code perhaps pushing an odd number of
words onto the stack, or am I maybe getting confused about the
Full-Descending addressing?

Funnily enough, the way I read the AAPCS, the first argument to sprintf
should be in R2:R3, and not on the stack...!

J