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.
next 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: linkBe 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).