From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30248 invoked by alias); 16 Feb 2011 22:49:38 -0000 Received: (qmail 30219 invoked by uid 22791); 16 Feb 2011 22:49:37 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Feb 2011 22:49:34 +0000 Received: by fxm12 with SMTP id 12so2001796fxm.0 for ; Wed, 16 Feb 2011 14:49:31 -0800 (PST) Received: by 10.223.83.199 with SMTP id g7mr1438051fal.97.1297896519414; Wed, 16 Feb 2011 14:48:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.154 with HTTP; Wed, 16 Feb 2011 14:47:19 -0800 (PST) In-Reply-To: <4D5C104D.7050707@redhat.com> References: <4D5ABAB2.2000405@redhat.com> <4D5ACDF2.20904@redhat.com> <4D5C104D.7050707@redhat.com> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Wed, 16 Feb 2011 22:49:00 -0000 Message-ID: Subject: Re: [avr] gas support for cfi info To: Richard Henderson Cc: Anitha Boyapati , binutils@sourceware.org, gdb@sourceware.org, GCC Patches , chertykov@gmail.com, aesok@post.ru, eric.weddington@atmel.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00200.txt.bz2 On 16 February 2011 18:58, Richard Henderson wrote: > Anitha pointed out to me via gcc pr17994 that AVR uses post-decrement > for its pushes. =C2=A0I 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. =C2=A0I.e. > > =C2=A0caller: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 callee: > =C2=A0 =C2=A0save rN > =C2=A0 =C2=A0save rM > =C2=A0 =C2=A0trash =C2=A0 =C2=A0<- SP =C2=A0hi(ret) =C2=A0<- CFA > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lo(r= et) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tras= h =C2=A0 =C2=A0<- 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. =C2=A0This 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 ... --=20 Petr Hluzin