This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: AArch64 calling convention in assembly code
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Alexander Fedotov <alfedotov at gmail dot com>, Newlib <newlib at sourceware dot org>, gdb at sourceware dot org
- Date: Wed, 1 Aug 2018 14:03:25 -0400
- Subject: Re: AArch64 calling convention in assembly code
- References: <CAN8C2CqGq4OUNXq5=ur87nqwVjYF-D6aAcVKGGB1pQT1S0b6Jg@mail.gmail.com> <CAN8C2CrGOT9GrV=AhY1JB_8A1owNA_3nBaMs8xUffwHALf3h2A@mail.gmail.com> <cc3376cb-0735-bff6-7417-77eb3f08675a@arm.com> <CAN8C2CpFLhxZ5Veca=y2=wbeOtxgnm16LPpCdN7ZKCKh6WEVSw@mail.gmail.com> <4fae7e81-fcf0-59e7-0770-f0eea9e96d44@arm.com>
I have pushed Richard's patch to master.
-- Jeff J.
On Wed, Aug 1, 2018 at 12:19 PM, Richard Earnshaw (lists) <
Richard.Earnshaw@arm.com> wrote:
> On 01/08/18 16:56, Alexander Fedotov wrote:
> > Yes, but X29 is not saved in original version. I can understand this
> > with 'frame-less functions" approach. So this code has a right for a
> > life.
> >
> > I suspect that such a problem could happen if user will pass
> > "-fomit-frame-pointer" option to GCC as well.
> >
> >>> All we really need is a CFI unwind record that GDB can understand.
> > For plain assembly code ?
> >
>
> Yep, see attached. This also simplifies the entry/exit sequences slightly.
>
>
> * aarch64/cpu-init/rdimon-aem-el3.S (cpu_init_hook): Simplify
> entry/exit sequences. Add CFI unwind rules.
>
> R.
>
> > Alex
> >
> > On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists)
> > <Richard.Earnshaw@arm.com> wrote:
> >> On 01/08/18 14:28, Alexander Fedotov wrote:
> >>>>> Pushing LR on the stack resolves a problem
> >>> FP of course, not LR.
> >>> So the correct code must be like this:
> >>>
> >>> _cpu_init_hook:
> >>> stp x29, x30, [sp, #-16]!
> >>> mov x29, sp
> >>> bl _init_vectors
> >>> bl _flat_map
> >>> ldp x29, x30, [sp], #16
> >>> ret
> >>>
> >>> But still my point is that GDB should catch such an error and do not
> hang.
> >>>
> >>> Alex
> >>>
> >>> On Tue, Jul 31, 2018 at 9:34 PM, Alexander Fedotov <
> alfedotov@gmail.com> wrote:
> >>>> Hello dear AArch64 maintainers
> >>>> Please look into code snippet below from newlib/libgloss/aarch64/
> rdimon-aem-el3.
> >>>>
> >>>> Seems to me this code violates AArch64 calling convention and actually
> >>>> breaks debugging in GDB. GDB tries to unwind call stack and got
> >>>> endless reentrancy...
> >>>>
> >>>> FUNCTION (_cpu_init_hook):
> >>>> sub sp, sp, #16
> >>>> str x30, [sp, xzr]
> >>>> bl _init_vectors
> >>>> bl _flat_map
> >>>> ldr x30, [sp, xzr]
> >>>> add sp, sp, #16
> >>>> ret
> >>>>
> >>>>
> >>>> We have couple of calls there (_init_vectors, _flat_map). If you'll
> >>>> try to step into any subroutine you will found that GDB hangs and
> >>>> can't step anymore.
> >>>>
> >>>> Pushing LR on the stack resolves a problem.
> >>
> >> X30 is LR.
> >>
> >> All we really need is a CFI unwind record that GDB can understand.
> >>
> >> R.
> >>
> >>>>
> >>>> So my message is that:
> >>>> 1. Current code in _cpu_init_hook is incorrect
> >>>> 2. GDB should handle this and do not hang
> >>>>
> >>>> Alex
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>