From: Roland McGrath <roland@hack.frob.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: <libc-ports@sourceware.org>, <macro@codesourcery.com>
Subject: Re: Add CFI information for MIPS assembly sources
Date: Fri, 08 Feb 2013 00:47:00 -0000 [thread overview]
Message-ID: <20130208004718.C3AA12C098@topped-with-meat.com> (raw)
In-Reply-To: Joseph S. Myers's message of Friday, 8 February 2013 00:41:53 +0000 <Pine.LNX.4.64.1302080026390.17419@digraph.polyomino.org.uk>
> 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.
> (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.)
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.
Thanks,
Roland
next prev parent reply other threads:[~2013-02-08 0:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 22:52 Joseph S. Myers
2013-02-08 0:08 ` Roland McGrath
2013-02-08 0:42 ` Joseph S. Myers
2013-02-08 0:47 ` Roland McGrath [this message]
2013-02-08 1:06 ` Joseph S. Myers
2013-02-08 14:57 ` Maciej W. Rozycki
2013-02-08 16:30 ` Joseph S. Myers
2013-02-08 17:52 ` Maciej W. Rozycki
2013-02-08 21:11 ` Joseph S. Myers
2013-02-11 18:20 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130208004718.C3AA12C098@topped-with-meat.com \
--to=roland@hack.frob.com \
--cc=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=macro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).