linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: linux-arch@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>, H.
Subject: [patch 0/4] [RFC] mcount address adjustment
Date: Tue, 10 May 2011 10:10:39 +0200	[thread overview]
Message-ID: <20110510081039.241831019@de.ibm.com> (raw)

This series of patches aims to simplify the mcount address adjustment for
ftrace. The frace code wants to know the start address of each function,
not the address of the relocation against the mcount symbol which have
been recorded to the __mcount_loc section. The ftrace_call_adjust function
is used to calculate the start address of the function from the mcount
relocation at runtime.

For x86, ia64 and s390 the adjustment is a constant offset. There is no
need to do the adjustment at runtime, it can be done by recordmcount at
compile time. Blackfin already does this with the mcount_adjust variable
in the pearl version of recordmcount. After teaching the C version of
recordmcount about mcount_adjust x86, ia64 and s390 can be converted to
a nop ftrace_call_adjust function.

That leaves arm as the last remaining architecture with a non trivial
ftrace_call_adjust function. There the least significant bit is removed
from the address with an and operation. The comment says this is done
for Thumb-2. This implies that for Thumb-1 the offset is 0 and for
Thumb-2 the offset is -1, correct? If there is a way to distinguish
the two targets in recordmcount at compile time we could convert arm
as well. Which would allow us to remove the ftrace_call_adjust function.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: linux-arch@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Russell King <linux@arm.linux.org.uk>,
	Rabin Vincent <rabin@rab.in>
Subject: [patch 0/4] [RFC] mcount address adjustment
Date: Tue, 10 May 2011 10:10:39 +0200	[thread overview]
Message-ID: <20110510081039.241831019@de.ibm.com> (raw)
Message-ID: <20110510081039.mrGEGpXb-lPG-krYy9C3n_nFpvAeonouZcTncOp1Ijs@z> (raw)

This series of patches aims to simplify the mcount address adjustment for
ftrace. The frace code wants to know the start address of each function,
not the address of the relocation against the mcount symbol which have
been recorded to the __mcount_loc section. The ftrace_call_adjust function
is used to calculate the start address of the function from the mcount
relocation at runtime.

For x86, ia64 and s390 the adjustment is a constant offset. There is no
need to do the adjustment at runtime, it can be done by recordmcount at
compile time. Blackfin already does this with the mcount_adjust variable
in the pearl version of recordmcount. After teaching the C version of
recordmcount about mcount_adjust x86, ia64 and s390 can be converted to
a nop ftrace_call_adjust function.

That leaves arm as the last remaining architecture with a non trivial
ftrace_call_adjust function. There the least significant bit is removed
from the address with an and operation. The comment says this is done
for Thumb-2. This implies that for Thumb-1 the offset is 0 and for
Thumb-2 the offset is -1, correct? If there is a way to distinguish
the two targets in recordmcount at compile time we could convert arm
as well. Which would allow us to remove the ftrace_call_adjust function.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

             reply	other threads:[~2011-05-10  8:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10  8:10 Martin Schwidefsky [this message]
2011-05-10  8:10 ` [patch 0/4] [RFC] mcount address adjustment Martin Schwidefsky
2011-05-10  8:10 ` [patch 1/4] recordmcount " Martin Schwidefsky
2011-05-10  8:10   ` Martin Schwidefsky
2011-05-10  8:10 ` [patch 2/4] x86 mcount offset calculation Martin Schwidefsky
2011-05-10  8:10   ` Martin Schwidefsky
2011-05-10  8:10 ` [patch 3/4] ia64 " Martin Schwidefsky
2011-05-10  8:10   ` Martin Schwidefsky
2011-05-16 18:58   ` Steven Rostedt
2011-05-16 19:17     ` Luck, Tony
2011-05-16 19:17       ` Luck, Tony
2011-05-16 20:41       ` Steven Rostedt
2011-05-17  8:04       ` Martin Schwidefsky
2011-05-17 11:20         ` Steven Rostedt
2011-05-10  8:10 ` [patch 4/4] s390 " Martin Schwidefsky
2011-05-10  8:10   ` Martin Schwidefsky
2011-05-11 17:23 ` [patch 0/4] [RFC] mcount address adjustment Rabin Vincent
2011-05-12  9:24   ` Martin Schwidefsky
2011-05-12 13:30     ` Rabin Vincent
2011-05-16 12:57       ` Dave Martin
2011-05-16 14:28         ` Steven Rostedt

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=20110510081039.241831019@de.ibm.com \
    --to=schwidefsky@de.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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).