This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Adding CFI statements to ARM's assembly code
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: libc-ports at sourceware dot org
- Date: Thu, 31 Dec 2009 16:57:25 +0000 (UTC)
- Subject: Re: Adding CFI statements to ARM's assembly code
- References: <878wcw5lyc.fsf@dirichlet.schwinge.homeip.net>
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