This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding CFI statements to ARM's assembly code


On Mon, 21 Dec 2009, Thomas Schwinge wrote:

> In spirit with previous ARM code enhancements,
> (cf. <http://sourceware.org/ml/libc-ports/2009-12/msg00012.html>), only
> the EABI and NPTL code will be changed.

Although as discussed files not relevant to EABI and NPTL do not need 
updating, all files that *are* relevant to EABI and NPTL, and that use the 
ENTRY macro so this patch series makes them use cfi_startproc, and that 
adjust stack layout or clobber call-preserved registers so they need 
nontrivial CFI, do need to be updated before the patch series can go in, 
so they don't start having inaccurate debug information.

As far as I can see, the following files need updating:

sysdeps/arm/eabi/arm-mcount.S
sysdeps/unix/sysv/linux/arm/clone.S
sysdeps/unix/sysv/linux/arm/eabi/____longjmp_chk.S
sysdeps/unix/sysv/linux/arm/eabi/nptl/unwind-forcedunwind.c
sysdeps/unix/sysv/linux/arm/eabi/nptl/unwind-resume.c
sysdeps/unix/sysv/linux/arm/nptl/pt-vfork.S
sysdeps/unix/sysv/linux/arm/nptl/vfork.S

Please let me know if your list of files still needing updating is 
different.  I think the changes in the five-patch series starting at 
<http://sourceware.org/ml/libc-ports/2009-12/msg00020.html> are correct; 
it's just that more files need updating for the series to be able to go 
in.

Updating arm-mcount.S may be of limited help to the debugger without a fix 
to GCC PR 42380, but it's still the right thing to do.

The two C files define functions using toplevel asms, and those functions 
save registers to and restore them from the stack.  They don't use ENTRY 
so do not need fixing for the patch series to go in, but correct 
.debug_frame for the point when the stack is adjusted would still be 
useful.

clone is the trickiest case.  From other architectures, I think you want 
to call cfi_endproc immediately after the syscall because the correct CFI 
will be different in the parent and in the child.  At the start of code 
for the child, you can then call cfi_startproc again and mark lr as 
undefined with cfi_undefined; backtraces in a new thread should not go 
back before clone.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]