All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Christoph Hellwig <hch@lst.de>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: types for storing instruction pointers
Date: Mon, 8 Jun 2009 15:51:06 +0200	[thread overview]
Message-ID: <20090608135106.GA2276@lst.de> (raw)
In-Reply-To: <20090607132516.GB12088@elte.hu>

On Sun, Jun 07, 2009 at 03:25:16PM +0200, Ingo Molnar wrote:
> 
> * Christoph Hellwig <hch@lst.de> wrote:
> 
> > Currently the _THIS_IP_ and _RET_IP_ macros aded for lockdep but 
> > now available from kernel.org case the instruction pointer to an 
> > unsigned long.  But the %pf/%pF format for printing them want a 
> > pointer of some sort.  That's a pretty nasty situation for tracers 
> > - can we standardize on one type for it?
> 
> Yes but what's the practical problem exactly? Could you cite an 
> example?

The simplest tracer in xfs showing this is the following:

/*
 * ilock/iolock tracer
 *
 * Reports the inode, operation, flags and caller for each operation
 * on the inode locks.
 */
TRACE_EVENT(xfs_ilock,
	TP_PROTO(struct xfs_inode *ip, const char *op, unsigned lockflags,
		 unsigned long caller_ip),
	TP_ARGS(ip, op, lockflags, caller_ip),

	TP_STRUCT__entry(
		__field(dev_t, dev)
		__field(xfs_ino_t, ino)
		__field(const char *, op)
		__field(int, lockflags)
		__field(unsigned long, caller_ip)
	),

	TP_fast_assign(
		__entry->dev = VFS_I(ip)->i_sb->s_dev;
		__entry->ino = ip->i_ino;
		__entry->op = op;
		__entry->lockflags = lockflags;
		__entry->caller_ip = caller_ip;
	),

	TP_printk("dev %d:%d ino 0x%lld %s %s by %pF",
		  MAJOR(__entry->dev), MINOR(__entry->dev),
		  __entry->ino,
		  __entry->op,
		  __print_flags(__entry->lockflags, "|", XFS_LOCK_FLAGS),
		  (void *)__entry->caller_ip)
);

It has the following callers:

	trace_xfs_ilock(ip, "lock", lock_flags, _RET_IP_);
	trace_xfs_ilock(ip, "lock_nowait", lock_flags, _RET_IP_);
	trace_xfs_ilock(ip, "unlock", lock_flags, _RET_IP_);
	trace_xfs_ilock(ip, "demote", lock_flags, _RET_IP_);

Basically everything obtained via _RET_IP_/_THIS_IP_ needs to be
casted.  Given that both need to case the their return value to a
pointer that's rather unfortunately.  Life would be much easier
if _RET_IP_/_THIS_IP_ just returned a pointer (probably just a void
pointer, maybe with a fancy typedef to make it clear we're dealing
with an instruction pointer here).

  reply	other threads:[~2009-06-08 13:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-04 13:14 types for storing instruction pointers Christoph Hellwig
2009-06-07 13:25 ` Ingo Molnar
2009-06-08 13:51   ` Christoph Hellwig [this message]
2009-06-08 14:12     ` Ingo Molnar

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=20090608135106.GA2276@lst.de \
    --to=hch@lst.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.