Hello!
On 2009-12-15 10:15, Richard Earnshaw wrote:
> On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
>> .LCFI0:
>> .cfi_def_cfa_offset 8
>> + push {lr}
>> + bl __gnu_mcount_nc
>> .loc 1 4 0
>> mov r0, #33
>>
>> Shouldn't ``.cfi_adjust_cfa_offset 4'' or equivalent be emitted, too? If
>> I'm interpreting the .debug_frame correctly that is generated directly by
>> GCC without using CFI statemnts, it seems to have the same problem. Or
>> am I misunderstanding something?
>
> __gnu_mcount_nc is magic, it will pop that stack value before returning;
> so while there's a slight inconsistency for those two instructions,
> everything will be correct for the main body of the function.
Yes, that's correct -- I was indeed concerned about the invalid CFA that
occurs between push {lr}; bl __gnu_mcount_nc and until __gnu_mcount_nc
does its final pop {r0-r3, ip, lr}.
To give some context: I'm currently adding CFI statements to all (well,
most) of the assembly code in glibc's ARM sysdep files to help GDB figure
out frame unwinding in the case that its heuristics fail; for example in
all cases where cancellable syscalls are involved in multi-threaded
processes.
And of course, if the CFA is invalid already when entering
__gnu_mcount_nc, it's difficult for me to do the CFI annotation correctly
in there. (Or I begin __gnu_mcount_nc with .cfi_adjust_cfa_offset 4
which seems a bit ugly.)
> Any, this isn't the right place for this; could you raise a bug report
> in bugzilla please?
Done: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380>
Regards,
Thomas
pgp030wwzWqXE.pgp
Description: PGP signature
