From: Roland McGrath <roland@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: utrace comments
Date: Thu, 10 May 2007 01:49:26 -0700 (PDT) [thread overview]
Message-ID: <20070510084926.65D6558002@magilla.localdomain> (raw)
In-Reply-To: Christoph Hellwig's message of Monday, 30 April 2007 10:08:40 +0100 <20070430090840.GB31397@infradead.org>
> No need to renumber. You remove TIF_SYSCALL_EMU which is six,
> so the newly added TIF_FORCED_TF could reuse that bit.
No, that would be incorrect. As I mentioned earlier, there are magic
semantics to bits < 16, namely that they are in _TIF_ALLWORK_MASK (and
assembly code knows implicitly that these are in the low 16 bits).
TIF_FORCED_TF must not be in _TIF_ALLWORK_MASK, hence must be >= 16.
> > Ok. The kerneldoc stuff is new and strange to me, and I've never
> > personally experienced its benefical features. But I've read
> > Documentation/kernel-doc-nano-HOWTO.txt now and I will try to convert all
> > my documentary comments to that style.
>
> Thanks. If you need some help ping me or Randy.
I've converted the comments to kerneldoc style where I could figure out how
to. I left some unmarked comments in places I couldn't see how to get them
extracted from. I'd appreciate any specific advice you have for the
descriptive comments as they now stand.
> Current gcc (since 3.<something>) can optimize away code under if-branches
> that are determinable at compile time, so having each architecture
> define a (possible trivial) arch_has_single_step() should be fine.
What I had in mind was whole chunks of code you might not build, including
global symbols or whole modules. In particular, I expect to have some
utility code for executing a single copied instruction (in the style of
kprobes), which can also be implemented for machines without single-step
(see kprobes ARM port). That could be employed to simulate single-stepping
by a tracing engine (though not without complexities and caveats, which is
why it won't be built in as the UTRACE_ACTION_SINGLESTEP support). An
engine could support this using only machine-independent interfaces to the
aforementioned utility code, and rely on arch_has_single_step() to know
whether it needs to. That code might be costly to build in and would not
all be dropped at compile time even if always dead at runtime, or perhaps
isn't there at all for a particular machine. But if on that machine you
know at compile time that arch_has_single_step() will never return 0, you
don't need it. I don't want to get too bogged down in those specifics,
because they aren't the point right now. The only point I'm making here is
that #if really is going to be useful.
> Btw, is there a fundamental reason why an architecture would not support
> single-stepping except for a transition period of porting, i.e. are there
> real hardware limitation in any of our ports?
As I understand it, Alpha and ARM hardware in fact have no single-step feature.
There may be others.
> > utrace_native_view is expected to be the only user of the *_view symbols.
> > I inlined it because on single-arch platforms it's just a constant return
> > and I didn't want to add another useless call frame. I admit this is undue
> > microoptimization. Perhaps utrace_native_view should just be non-inlined
> > and exported.
>
> Yeah, the latter probably makes sense.
I've changed it that way now.
Thanks,
Roland
next prev parent reply other threads:[~2007-05-10 8:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-27 16:51 Christoph Hellwig
2006-12-05 9:51 ` Roland McGrath
2006-12-06 21:58 ` Christoph Hellwig
2007-04-30 4:02 ` Roland McGrath
2007-04-30 9:08 ` Christoph Hellwig
2007-04-30 9:18 ` Russell King
2007-04-30 9:22 ` Christoph Hellwig
2007-04-30 9:33 ` Russell King
2007-04-30 9:45 ` Russell King
2007-04-30 10:32 ` Christoph Hellwig
2007-04-30 10:18 ` Christoph Hellwig
2007-06-22 2:40 ` Roland McGrath
2007-05-10 8:49 ` Roland McGrath [this message]
2007-04-30 9:11 ` condingstyle, was " Christoph Hellwig
2007-04-30 17:09 ` Andrew Morton
2007-04-30 18:19 ` Jan Engelhardt
2007-04-30 18:39 ` Daniel Hazelton
2007-04-30 18:42 ` Satyam Sharma
2007-04-30 22:18 ` Stefan Richter
2007-05-01 9:00 ` Geert Uytterhoeven
2007-05-01 13:11 ` Scott Preece
2007-05-01 14:16 ` David Woodhouse
2007-05-01 15:00 ` John Anthony Kazos Jr.
2007-05-01 20:12 ` Satyam Sharma
2007-05-01 15:05 ` Randy Dunlap
2007-05-01 15:06 ` David Woodhouse
2007-05-01 20:44 ` Satyam Sharma
2007-05-01 15:07 ` Geert Uytterhoeven
2007-05-01 15:11 ` David Woodhouse
2007-05-01 16:07 ` David Howells
2007-05-02 2:18 ` Eric W. Biederman
2007-05-02 9:32 ` David Howells
2007-05-02 11:55 ` Eric W. Biederman
2007-05-02 12:05 ` David Howells
2007-05-01 16:15 ` Stuart MacDonald
2007-04-30 21:34 ` Luck, Tony
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=20070510084926.65D6558002@magilla.localdomain \
--to=roland@redhat.com \
--cc=hch@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®