AArch64 calling convention in assembly code
Jeff Johnston
jjohnstn@redhat.com
Wed Aug 1 20:06:00 GMT 2018
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
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
More information about the Newlib
mailing list