Re: AArch64 calling convention in assembly code

I have pushed Richard's patch to master.

-- Jeff J.

On Wed, Aug 1, 2018 at 12:19 PM, Richard Earnshaw (lists) <
[email protected]> 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)
> > <[email protected]> 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 <
> [email protected]> 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
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>