Re: Add CFI information for MIPS assembly sources

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 7 Feb 2013, Roland McGrath wrote:

> > Unfortunately sys/asm.h is an installed header implementing some 
> > externally-defined SGI API, but also used internally in glibc for various 
> > things.  So the CFI in start/end of function macros there is using 
> > implementation-namespace __mips_cfi_* macros (existing practice for other 
> > architectures being to put CFI in the start/end of function macros), 
> > defined conditionally on _LIBC, and any variation on SETUP_GP64 would I 
> > suppose also need to be in the implementation namespace or conditioned on 
> > _LIBC.  (For a non-architecture-specific header you might have an internal 
> > include/sys/asm.h for internal macros, but that's not an option here.  Or 
> > put the variants in sysdep.h, but that's separating macros from 
> > closely-related other macros.)
> 
> For other similar reasons I've been considering supporting
> sysdeps/.../include/ directories.  Those would be in the -I list for
> building libc, but not in sysdirs and so not candidates for installation.
> I can do the makefile hackery if you'd like to use that.

I agree such directories would be useful for handling the sys/asm.h 
changes more cleanly.

> Then if it were me I'd just leave out the SETUP_GP* cases in the first
> patch and leave them for after the blocking issues were cleared out in
> further incremental changes.

I'd rather not have too much inaccurate / incomplete CFI (as opposed to 
code with no CFI at all), although since none of the affected places are 
valid for throwing exceptions through, the effects are much the same as 
for no CFI (inaccurate register values in backtraces e.g. with GDB, in the 
gp cases).  (I think with this patch, CFI is present but incomplete / 
inaccurate only for __syscall_error and a few instructions in setcontext, 
but not for the lots of other functions that save and restore gp.)

-- 
Joseph S. Myers
joseph@codesourcery.com