From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-182007-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8387 invoked by alias); 13 Feb 2014 14:32:43 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 8374 invoked by uid 89); 13 Feb 2014 14:32:42 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: service87.mimecast.com
Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2014 14:32:41 +0000
Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Thu, 13 Feb 2014 14:32:38 +0000
Received: from [10.1.205.157] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959);	 Thu, 13 Feb 2014 14:32:39 +0000
Message-ID: <52FCD786.1040407@arm.com>
Date: Thu, 13 Feb 2014 14:32:00 -0000
From: Renlin Li <renlin.li@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Shiva Chen <shiva0217@gmail.com>
CC: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Aarch64 implementation for dwarf exception handling
References: <CAH=PD7byDjYwq3KjpR=THt-HO6a73Zy9abq8_Zttg8kqjy-VMw@mail.gmail.com>
In-Reply-To: <CAH=PD7byDjYwq3KjpR=THt-HO6a73Zy9abq8_Zttg8kqjy-VMw@mail.gmail.com>
X-MC-Unique: 114021314323811501
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2014-02/txt/msg00185.txt.bz2

On 13/02/14 02:14, Shiva Chen wrote:
> Hi,
>
> I have a question about the implementation of
>
> aarch64_final_eh_return_addr
>
> which is used to point out the return address of the frame
>
> According the source code
>
> If FP is not needed
>
>    return gen_frame_mem (DImode,
>                          plus_constant (Pmode,
>                                         stack_pointer_rtx,
>                                         fp_offset
>                                         + cfun->machine->frame.saved_regs=
_size
>                                         - 2 * UNITS_PER_WORD));
>
>
> According the frame layout
>
>          +-------------------------------+ <-- arg_pointer_rtx
>          |
>          |  callee-allocated save area
>          |  for register varargs
>          |
>          +-------------------------------+
>          |
>          |  local variables
>          |
>          +-------------------------------+ <-- frame_pointer_rtx
>          |
>          |  callee-saved registers
>          |
>          +-------------------------------+
>          |  LR'
>          +-------------------------------+
>          |  FP'
>         P+-------------------------------+ <-- hard_frame_pointer_rtx
>          |  dynamic allocation
>          +-------------------------------+
>          |
>          |  outgoing stack arguments
>          |
>          +-------------------------------+ <-- stack_pointer_rtx
>
> Shouldn't the return value be
>
>    return gen_frame_mem (DImode,
>                          plus_constant (Pmode,
>                                         stack_pointer_rtx,
>                                         fp_offset
>                                         +  2* UNITS_PER_WORD));
>
> Or I just mis-understanding something ?
>
>
> Hope someone could give me a tip.
>
> It would be very helpful.
>
> Thanks
>
> Shiva Chen
>
Hi,

If frame pointer is not needed. The prologue routine will store the=20
callee saved registers to stack according to ascending order, which=20
means X0 will be saved first if needed, and X30(LR) will be the last if=20
it's pushed into stack.

Please check the source code, aarch64_layout_frame().

As the comment above the code also indicates, LR would be at the top of=20
the saved registers block().

By the way, there is one additional stack slot might be needed to keep=20
stack pointer 16-byte aligned,  so - 2 * UNITS_PER_WORD is needed to=20
adjust the load  address.

         +-------------------------------+ <-- arg_pointer_rtx
         |
         +-------------------------------+ <-- frame_pointer_rtx
         |  dummy
         |  LR
         |  bla...bla...
         |  x3
         |  x2
         |  x1
         |  x0
       P +-------------------------------+ <-- hard_frame_pointer_rtx
         |
         +-------------------------------+ <-- stack_pointer_rtx


Kind regards,
Renlin