Re: Add CFI information for MIPS assembly sources

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Fri, 8 Feb 2013, Joseph S. Myers wrote:

> > 1. If I were the maintainer, I'd expect the change to convert sources to
> >    use ENTRY/END/etc. properly to be done separately, preferably before
> >    making changes to add CFI pieces so as not to obfuscate the actual 
> >    matter of this change.  It would make people easier to review this 
> >    change too.  Of course it's you who are the MIPS maintainer, so it's 
> >    just my opinion, you're free to do whatever you like there.
> 
> I have committed this part separately.

 Thanks.

> > 2. Given the implementation I fail to see the point of modifying
> >    <sys/asm.h> at all.  Yes, it saves a line here or there, but at the
> >    cost of non-standard semantics, some obfuscation, and then you need to
> 
> Standard semantics in glibc are that cfi_startproc and cfi_endproc go in 
> the macros used to define the start and end of functions, rather than in 
> the .S files using those macros (except in special cases where it's 
> necessary to avoid CFI covering part of a function, e.g. for clone).
> 
> Roland's addition of a sysdeps/.../include mechanism should allow most of 
> the internal macros to go in sysdeps/mips/include/sys/asm.h rather than 
> the installed header, although some changes will still be needed to the 
> installed header to add the use of __mips_cfi_* to the relevant macros.

 Hmm, this overall sounds like a good idea to me, however I still feel a 
bit uneasy about fiddling with these standard (as far as MIPS usage is 
concerned) macros in a publicly installed header.  At the same time I 
realise the semantics of the C preprocessor language makes it difficult to 
overload macros without pasting the same body over and over again.

 However it should be possible to wrap the macros into other ones by using 
a different name.  This way the public macros would remain intact (yes, I 
do have a concern as to the consistency of <sys/asm.h> vs <asm/asm.h> -- 
they share a common ancestor, they provide abstract definitions that have 
nothing to do specifically with userland or Linux kernel code and are both 
meant to serve the same purpose, so the fewer divergences the better), 
e.g.

#define _LIBC_LEAF(symbol)	\
  LEAF (symbol)			\
  cfi_startproc

(or perhaps call it _CFI_LEAF instead?).  What do you think?  Likewise the 
others, and...

> > 3. On the other hand it may be worthwhile to avoid obfuscation like:
> > 
> > # if _MIPS_SIM != _ABIO32
> > 	cfi_rel_offset (gp, GPOFF)
> > # endif
> > 
> >    and define a macro like mips_cfi_rel_offset64 (a better name may be
> >    possible, perhaps just cfi_rel_offset64) that'll handle the ABI 
> >    condition in the definition, pretty much like SETUP_GP64 does.  
> >    Likewise with complementing cfi_restore.
> 
> SETUP_GP64_REG and SETUP_GP64_STACK (and similar RESTORE_GP64_*) are what 
> I'm thinking of for include/sys/asm.h (the internal header) to combine the 
> calls to the existing macros with providing CFI information.

 ... that would solve the issue of these macros as well.

  Maciej