From: "Joseph S. Myers" <joseph@codesourcery.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: <libc-ports@sourceware.org>
Subject: Re: Add CFI information for MIPS assembly sources
Date: Fri, 08 Feb 2013 21:11:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1302082108540.341@digraph.polyomino.org.uk> (raw)
In-Reply-To: <alpine.DEB.1.10.1302081735270.6762@tp.orcam.me.uk>
On Fri, 8 Feb 2013, Maciej W. Rozycki wrote:
> 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...
I don't think having yet more macros for start and end of functions would
be an improvement; it seems clearly better for functions to use END where
possible, in particular, and that's in both sys/asm.h and sysdep.h (and
while the definitions are such that the one in sysdep.h would take
precedence if both are included, having different definitions of the same
macro in those two headers would seem just too confusing).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-02-08 21:11 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
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 [this message]
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=Pine.LNX.4.64.1302082108540.341@digraph.polyomino.org.uk \
--to=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).