This is the mail archive of the
mailing list for the libc-ports project.
Re: Add CFI information for MIPS assembly sources
On Fri, 8 Feb 2013, Maciej W. Rozycki 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.
> 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.
> 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.
Joseph S. Myers