This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [avr] gas support for cfi info
- From: Petr HluzÃn <petr dot hluzin at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Anitha Boyapati <anitha dot boyapati at gmail dot com>, binutils at sourceware dot org, gdb at sourceware dot org, GCC Patches <gcc-patches at gcc dot gnu dot org>, chertykov at gmail dot com, aesok at post dot ru, eric dot weddington at atmel dot com
- Date: Wed, 16 Feb 2011 23:47:19 +0100
- Subject: Re: [avr] gas support for cfi info
- References: <AANLkTim6hyXysiV-025BDgNJ84qaqTnkRdHi+e7bF2gx@mail.gmail.com> <AANLkTi=Rnu-wb2W8FejN=XQHmHuTq7rZovKuDdO-QLwi@mail.gmail.com> <AANLkTimOXF1V__SSFs1gtqJh5nc183EdeHm5NoeU6YXs@mail.gmail.com> <AANLkTike2osnZS=sUphuN_=oFQLCDUs54uuGCWL6cLVQ@mail.gmail.com> <4D5ABAB2.2000405@redhat.com> <4D5ACDF2.20904@redhat.com> <AANLkTinco6ZrrBGYh3ipDzPmw8D3jt5_KjfJF1xvE4WM@mail.gmail.com> <4D5C104D.7050707@redhat.com>
On 16 February 2011 18:58, Richard Henderson <rth@redhat.com> wrote:
> Anitha pointed out to me via gcc pr17994 that AVR uses post-decrement
> for its pushes. ÂI had a brief read over the AVR insn manual, and it's
> not crystal clear how multi-byte post-decrement pushes operate.
>
> I've made an assumption that it happens as-if each byte is pushed
> separately. ÂI.e.
>
> Âcaller: Â Â Â Â Â callee:
> Â Âsave rN
> Â Âsave rM
>  Âtrash  Â<- SP Âhi(ret) Â<- CFA
> Â Â Â Â Â Â Â Â Â Âlo(ret)
>          Âtrash  Â<- SP
>
> This is the only way I can imagine that call insns interoperate with
> byte push/pop insns.
Yes, except the bytes of return address are in big-endian. See
avr-tdep.c in function avr_frame_prev_register():
/* ...
And to confuse matters even more, the return address stored
on the stack is in big endian byte order, even though most
everything else about the avr is little endian. Ick! */
> All of which means that the return address is at a different offset
> from the CFA than I originally thought. ÂThis ought to be fixed in
> the following.
>
> Can someone please test these two patches and see if they actually
> agree with the hardware?
What should I look for when testing?
The layout of stack you draw is correct (minus the endianity), see avr-tdep.c:
/* Any function with a frame looks like this ...
--
Petr Hluzin