As other people are saying, code seems to be jumped at at #6.
Well yeah, that's what I said above.
LR is being clobbered by the blx
There's no blx in the first section. These first six bytes would only make sense if this small stub ended in bx lr, therefore I don't think it's a valid function.
Normally you'd save more than just PC as AAPCS (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aap...) mandates stack to be aligned to 8 bytes for "public interface" functions. But this is is not a "public" function so it's fine to only save lr here.
"bx lr" is only used on it's own when the function doesn't call another function (altering lr), and doesn't need to save any registers.
If you see pop {lr}; bx lr then that's code that's being compiled to explicitly support Armv4 (e.g. Arm7TDMI)
Comments
Only if there's a corresponding push { ..., lr }, but in this case there isn't. I'd expect bx lr here.
As other people are saying, code seems to be jumped at at #6.
LR is being clobbered by the bl (EDIT: bl, not blx)
Well yeah, that's what I said above.
There's no blx in the first section. These first six bytes would only make sense if this small stub ended in bx lr, therefore I don't think it's a valid function.
Normally you'd save more than just PC as AAPCS (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aap...) mandates stack to be aligned to 8 bytes for "public interface" functions. But this is is not a "public" function so it's fine to only save lr here.
"bx lr" is only used on it's own when the function doesn't call another function (altering lr), and doesn't need to save any registers.
If you see pop {lr}; bx lr then that's code that's being compiled to explicitly support Armv4 (e.g. Arm7TDMI)
EDIT: https://gcc.godbolt.org/z/TadnqescT