AArch64 calling convention in assembly code

Post by Alexander Fedotov
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

Post by Alexander Fedotov
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...
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.
1. Current code in _cpu_init_hook is incorrect
2. GDB should handle this and do not hang
Alex

--
Best regards,
AF

Richard Earnshaw (lists)

2018-08-01 15:48:58 UTC

Post by Alexander Fedotov
Pushing LR on the stack resolves a problem

FP of course, not LR.
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

X30 is LR.

All we really need is a CFI unwind record that GDB can understand.

R.

Post by Alexander Fedotov
1. Current code in _cpu_init_hook is incorrect
2. GDB should handle this and do not hang
Alex

Alexander Fedotov

2018-08-01 15:56:55 UTC

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.

Post by Richard Earnshaw (lists)
All we really need is a CFI unwind record that GDB can understand.

For plain assembly code ?

Alex

On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists)

Post by Alexander Fedotov
Pushing LR on the stack resolves a problem

FP of course, not LR.
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

X30 is LR.
All we really need is a CFI unwind record that GDB can understand.
R.

Post by Alexander Fedotov
1. Current code in _cpu_init_hook is incorrect
2. GDB should handle this and do not hang
Alex

--
Best regards,
AF

Richard Earnshaw (lists)

2018-08-01 16:19:45 UTC

Post by Alexander Fedotov
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.

Post by Richard Earnshaw (lists)
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.

Post by Alexander Fedotov
Alex
On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists)

Post by Alexander Fedotov
Pushing LR on the stack resolves a problem

FP of course, not LR.
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

X30 is LR.
All we really need is a CFI unwind record that GDB can understand.
R.

Post by Alexander Fedotov
1. Current code in _cpu_init_hook is incorrect
2. GDB should handle this and do not hang
Alex

Jeff Johnston

2018-08-01 18:03:25 UTC

I have pushed Richard's patch to master.

-- Jeff J.

On Wed, Aug 1, 2018 at 12:19 PM, Richard Earnshaw (lists) <

Post by Richard Earnshaw (lists)
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.

Post by Alexander Fedotov
Alex
On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists)

Post by Alexander Fedotov
Pushing LR on the stack resolves a problem

FP of course, not LR.
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.

Post by Richard Earnshaw (lists)
Alex
On Tue, Jul 31, 2018 at 9:34 PM, Alexander Fedotov <

Post by Alexander Fedotov
Hello dear AArch64 maintainers
Please look into code snippet below from newlib/libgloss/aarch64/

rdimon-aem-el3.

Post by Alexander Fedotov
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...
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.

Post by Alexander Fedotov
1. Current code in _cpu_init_hook is incorrect
2. GDB should handle this and do not hang
Alex

Alexander Fedotov

2018-08-02 10:27:55 UTC

Richard, Jeff
Thank you !

BR,
Alex

Post by Jeff Johnston
I have pushed Richard's patch to master.
-- Jeff J.
On Wed, Aug 1, 2018 at 12:19 PM, Richard Earnshaw (lists)

Post by Richard Earnshaw (lists)
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.

Post by Alexander Fedotov
Alex
On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists)

Post by Alexander Fedotov
Pushing LR on the stack resolves a problem

FP of course, not LR.
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

Post by Alexander Fedotov
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...
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.