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: Add CFI information for MIPS assembly sources


On Thu, 7 Feb 2013, Roland McGrath wrote:

> > For SETUP_GP64 and RESTORE_GP64, the cfi_* directives are in the
> > individual .S files rather than the macro definitions because the
> > macros can be used to save the old gp value in either a register or a
> > stack slot, and those need different CFI directives, so a single macro
> > SETUP_GP64 can't handle both cases and generate CFI at the same time.
> 
> It seems much cleaner to define two pairs of macros for the two cases,
> so that the macros can contain the CFI details too.  Separating the code
> from the CFI like you've done will always be error-prone.  Using separate
> macros is less total text, as well as less duplication of magic numbers.

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.)

(Putting CFI within those macros would also then bring in the need to deal 
with CFI for inline asm in the same patch - those macros are used, 
stringized, in inline asm in dl-machine.h and dl-trampoline.c, which would 
then need at least .cfi_startproc/.cfi_endproc for the functions defined 
in inline asm.  So it would also make it harder to get in useful pieces of 
CFI incrementally without needing to add all the CFI for all of glibc at 
once.)

-- 
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]