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: Daniel Jacobowitz <dan at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-ports at sourceware dot org
- Date: Tue, 12 Jan 2010 09:52:38 -0500
- Subject: Re: Adding CFI statements to ARM's assembly code
- References: <878wcw5lyc.fsf@dirichlet.schwinge.homeip.net> <Pine.LNX.4.64.0912311641360.2670@digraph.polyomino.org.uk> <87vdf7tphu.fsf@dirichlet.schwinge.homeip.net>
On Tue, Jan 12, 2010 at 02:35:41PM +0100, Thomas Schwinge wrote:
> Hello!
>
> On 2009-12-31 16:57, Joseph S. Myers wrote:
> > Please let me know if your list of files still needing updating is
> > different.
>
> Does sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S need any treatment?
> It's probably not worth it.
I'm a bit confused about that one. Doesn't ENTRY now generate
.cfi_startproc? There's nothing to generate .cfi_endproc, and I
thought a mismatch would fail to compile.
The signal restorer functions are somewhat special. It's easiest to
not give them CFI, because GDB and GCC know how to handle them if they
don't have CFI. If you do, we have to be pretty careful with it
(and e.g. use .cfi_signal_frame).
> In sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:INTERNAL_SYSCALL_RAW for
> [__thumb__], should we, depending on defined (__GCC_HAVE_DWARF2_CFI_ASM),
> emit CFI statements to handle r7's modification and restoral? We can't
> emit CFI statements unconditionally, as it's GCC's decision whether to
> emit .cfi_startproc or not, and in the latter case we're not allowed to
> using them in inline assembly.
In theory, we ought to. It's not very important since only r7 is
affected.
--
Daniel Jacobowitz
CodeSourcery