public inbox for linux-kernel@vger.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>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	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 11:16:09 -0700	[thread overview]
Message-ID: <45181CE9.1080204@goop.org> (raw)
In-Reply-To: <20060925151028.GA14695@Krystal>

Mathieu Desnoyers wrote:
> Good morning everyone,
>
> Following Jeremy Fitzhardinge's advice, I rewrote my marker mechanism taking in
> consideration inline functions (and therefore also unrolled loops). This new
> marker version is a complete rewrite of the previous one. It allows :
>
> - Multiple occurrences of the same marker name.
> - Declaration of a marker in an inline function.
> - Declaration of a marker in an unrolled loop.
> - It _does not_ change the compiler optimisations.
>   

Well, it will a little bit. If you put a mark on a statement which would 
have otherwise been removed, then it will not be removed; the labels 
effectively change the potential control flow graph as far as the 
compiler is concerned. But if marks are used appropriately the impact 
should be pretty minimal.

[MARK_CALL]
> +		asm volatile(	".section .markers, \"a\";\n\t" \
> +				".long %0, %1;\n\t" \
> +				".previous;\n\t" : : \
>   
[MARK_JUMP]
> +		asm volatile(	".section .markers, \"a\";\n\t" \
> +				".long %0, %1, %2;\n\t" \
> +				".previous;\n\t" : : \
> +			"m" (*&&jump_select_label), \
> +			"m" (*&&call_label), \
> +			"m" (*&&over_label)); \
>   

If you're going to put different types in the .markers section 
(presumably per-architecture, rather than different types for within one 
architecture) you should probably also define a structure in the same 
place, if nothing

> +		asm volatile (	".align 16;\n\t" : : ); \
> +		asm volatile (	".byte 0xeb;\n\t" : : ); \
> +jump_select_label: \
> +		asm volatile (	".byte %0-%1;\n\t" : : \
> +				"m" (*&&over_label), "m" (*&&call_label)); \
>   

There's absolutely nothing to guarantee that these three asm() will be 
kept together in the generated code, or in the same place with respect 
to any other asms.

> +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?

> +#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.

Also, expecting to call a varargs function from a non-varargs callsite 
is skating on very thin ice. Lots of architectures have very different 
calling conventions for varadic vs non-varadic functions, and I wouldn't 
rely on being able to make any sweeping generalizations about it. 
regparm is only documented to do anything on i386; it almost certainly 
won't make a non-varadic callsite look like a varadic call to a varadic 
function on architectures who's ABIs use different conventions for the 
two types of function.

J

  parent reply	other threads:[~2006-09-25 18:16 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 [this message]
2006-09-25 20:10   ` Mathieu Desnoyers
2006-09-25 20:25     ` Jeremy Fitzhardinge
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=45181CE9.1080204@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=mathieu.desnoyers@polymtl.ca \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox