All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Martin Bligh <mbligh@google.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	prasanna@in.ibm.com, Andrew Morton <akpm@osdl.org>,
	Ingo Molnar <mingo@elte.hu>, Paul Mundt <lethal@linux-sh.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jes Sorensen <jes@sgi.com>, Tom Zanussi <zanussi@us.ibm.com>,
	Richard J Moore <richardj_moore@uk.ibm.com>,
	Michel Dagenais <michel.dagenais@polymtl.ca>,
	Christoph Hellwig <hch@infradead.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	William Cohen <wcohen@redhat.com>,
	ltt-dev@shafik.org, systemtap@sources.redhat.com,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Karim Yaghmour <karim@opersys.com>, Pavel Machek <pavel@suse.cz>,
	Joe Perches <joe@perches.com>,
	"Randy.Dunlap" <rdunlap@xenotime.net>,
	"Jose R. Santos" <jrs@us.ibm.com>
Subject: Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
Date: Mon, 25 Sep 2006 13:25:04 -0700	[thread overview]
Message-ID: <45183B20.2080907@goop.org> (raw)
In-Reply-To: <20060925201036.GB13049@Krystal>

Mathieu Desnoyers wrote:
> I could declare my jump_select_label directly in assembly then.
>   

Maybe, but it could be tricky to make that label visible to C code.

>>> +call_label: \
>>> +		asm volatile ("" : : ); \
>>> +		MARK_CALL(name, format, ## args); \
>>> +		asm volatile ("" : : ); \
>>> +over_label: \
>>> +		asm volatile ("" : : ); \
>>>  
>>>       
>> These asm volatiles won't do anything at all. What are you trying to 
>> achieve?
>>     
>
> I want to make sure that the call_label's address will be exactly after the 2nd
> byte of the jump instruction. The over_label does not really matter, as long as
> it points to a correct spot in the execution flow. The most important is that
> it stays near the jump instruction.
>   

The "volatile" modifier for "asm" *only* means that the asm emitted if 
the code is reachable at all; it doesn't make any constraints about 
relative ordering of the various asm volatile statement with respect to 
each other, or with respect to other code.

> I could probably do all this in assembly too.
>   

Perhaps, though doing as much as possible visible to gcc has its 
benefits.  Tricky either way.

>>> +#ifdef CONFIG_MARKERS
>>> +#define MARK(name, format, args...) \
>>> +	do { \
>>> +		__label__ here; \
>>> +here:   	asm volatile(	".section .markers, \"a\";\n\t" \
>>> +				".long %0, %1;\n\t" \
>>> +				".previous;\n\t" : : \
>>> +			"m" (*(#name)), \
>>> +			"m" (*&&here)); \
>>>  
>>>       
>> Seems like a bad idea that MARK() can put one type of record in 
>> .markers, but MARK_JUMP and MARK_CALL can put different records in the 
>> same section? How do you distinguish them? Or are they certain to be 
>> exclusive? Either way, I'd probably put different mark records in 
>> different sections: .markers.jump, .markers.call, markers.labels. And 
>> define appropriate structures for the record types in each section.
>>
>>     
>
>
> struct __mark_marker {
>         const char *name;
>         const void *location;
>         char *select;
>         const void *jump_call;
>         const void *jump_over;
>         marker_probe_func **call;
>         const char *format;
> };
>
> is the structure which defines a complete record in the mark section. They are
> all tied to the same marker site, so I think it makes sense to keep them in the
> same record.
>   

I don't understand.  Your asms put things into the marker section with 
".long A, B, C".  Does does that correspond to this structure?

> Right, well, I wanted to keep a generic caller and try to make assumptions about
> the stack layout in the called function but if there is now way to do this, we
> can think of using the varargs in the probe.
>   

i386 is about the only architecture which uses the stack for calls by 
default.

    J

  reply	other threads:[~2006-09-25 20:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-25 15:10 [PATCH] Linux Kernel Markers 0.11 for 2.6.17 Mathieu Desnoyers
2006-09-25 16:01 ` Frank Ch. Eigler
2006-09-25 23:28   ` Mathieu Desnoyers
2006-09-26 16:39     ` Frank Ch. Eigler
2006-09-27  1:30       ` Mathieu Desnoyers
2006-09-27 16:12         ` Frank Ch. Eigler
2006-09-25 18:16 ` Jeremy Fitzhardinge
2006-09-25 20:10   ` Mathieu Desnoyers
2006-09-25 20:25     ` Jeremy Fitzhardinge [this message]
2006-09-25 20:35       ` Mathieu Desnoyers
2006-09-25 20:47         ` Mathieu Desnoyers
2006-09-25 21:22           ` Jeremy Fitzhardinge
2006-09-25 21:32             ` Mathieu Desnoyers
2006-09-25 21:35               ` Jeremy Fitzhardinge
2006-09-25 23:13   ` Mathieu Desnoyers

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=45183B20.2080907@goop.org \
    --to=jeremy@goop.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=compudj@krystal.dyndns.org \
    --cc=fche@redhat.com \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=jes@sgi.com \
    --cc=joe@perches.com \
    --cc=jrs@us.ibm.com \
    --cc=karim@opersys.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mbligh@google.com \
    --cc=michel.dagenais@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=prasanna@in.ibm.com \
    --cc=rdunlap@xenotime.net \
    --cc=richardj_moore@uk.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tglx@linutronix.de \
    --cc=wcohen@redhat.com \
    --cc=zanussi@us.ibm.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 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.