From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: "Frank Ch. Eigler" <fche@redhat.com>,
ltt-dev@shafik.org, systemtap@sources.redhat.com,
linux-sparse@vger.kernel.org
Subject: Linux Kernel Markers format string idea
Date: Thu, 21 Dec 2006 11:20:35 -0500 [thread overview]
Message-ID: <20061221162035.GA9609@Krystal> (raw)
Hi,
First, some context : I created the Linux Kernel Markers as a lightweight
code instrumentation mechanism with which we can connect a probe dynamically.
Type checking is done dynamically by comparing the string in the probe to the
string found at the instrumentation site. If we want to have strong type
checking with this mechanism, all the information used for typing must be in
the format string and validated. Frank showed some concerns about the use of
format strings regarding type checking. Here is a proposal to fix this.
I just had an idea about a format string extension that would help fix the
missing type checking with format strings for Linux Kernel Markers. It would
however imply that we extend the format string standard. One of the goals is
to keep backward compatibility with existing format strings.
The two sample cases I would like to "dynamically type check" are the
following :
- Passing a "struct mystruct *" as an argument.
- Passing a "__be64" as an argument
(typedef as "__u64 __bitwise", where __bitwise is undefined when compiled by
gcc but is defined as __attribute__((bitwise)) when compiled with __CHECKER__
for sparse).
(http://kernel.org/pub/linux/kernel/people/josh/sparse/)
The idea is to add the type between brackets after the conversion specifier.
For a pointer to a structure :
"%p[struct mystruct *]"
For a __be64 :
"%llu[__be64]"
The current format string validation of gcc will not perform more or less
validation than what is actually done, which is to verify that the type is a
pointer or a 64 bytes integer. Printing it through printk will show, for
instance :
0xfffffff[struct mystruct *]
1152921504606846976[__be64]
However, an enhanced format string verificator could check the type of the
pointer and the complete type of the __be64. It could start by being integrated
to the "checker", and only later make its way into gcc.
Comments on this idea are welcome.
Mathieu
--
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next reply other threads:[~2006-12-21 16:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-21 16:20 Mathieu Desnoyers [this message]
2006-12-26 19:48 ` Linux Kernel Markers format string idea Frank Ch. Eigler
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=20061221162035.GA9609@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=fche@redhat.com \
--cc=linux-sparse@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=systemtap@sources.redhat.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 NNTP newsgroup(s).