* [patch 0/4] [RFC] mcount address adjustment [not found] <20110510081039.241831019@de.ibm.com> @ 2011-05-11 17:23 ` Rabin Vincent 2011-05-12 9:24 ` Martin Schwidefsky 0 siblings, 1 reply; 5+ messages in thread From: Rabin Vincent @ 2011-05-11 17:23 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 10, 2011 at 13:40, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: > 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? ARM supports building the kernel using either the ARM instruction set or the Thumb-2 instruction set. The kernel cannot be built with the "Thumb-1" instruction set (btw usually referred to as just Thumb). Thumb-2 via recordmcount.pl needs the clearing of the lsb because the relocation (R_ARM_ABS32) that gets used for the assembly file that recordmcount.pl generates and assembles dictates that the lsb be set if the target symbol is Thumb/Thumb-2 function. mcount_adjust would not help here since the ORing is done later, when the relocation is applied. Thumb-2 via recordmcount.c does not need the clearing of the lsb in ftrace_call_adjust. Building with the ARM instruction set also does not need the clearing of the lsb. > 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. To remove ftrace_call_adjust, we could either deprecate the recordmcount.pl usage for ARM (you already have to edit the Kconfig to use it) or modify it to generate specific relocations explicitly instead of using the assembler data directives. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [patch 0/4] [RFC] mcount address adjustment 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 0 siblings, 1 reply; 5+ messages in thread From: Martin Schwidefsky @ 2011-05-12 9:24 UTC (permalink / raw) To: linux-arm-kernel On Wed, 11 May 2011 22:53:55 +0530 Rabin Vincent <rabin@rab.in> wrote: > On Tue, May 10, 2011 at 13:40, Martin Schwidefsky > <schwidefsky@de.ibm.com> wrote: > > 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? > > ARM supports building the kernel using either the ARM instruction set or > the Thumb-2 instruction set. The kernel cannot be built with the > "Thumb-1" instruction set (btw usually referred to as just Thumb). > > Thumb-2 via recordmcount.pl needs the clearing of the lsb because the > relocation (R_ARM_ABS32) that gets used for the assembly file > that recordmcount.pl generates and assembles dictates that the lsb be > set if the target symbol is Thumb/Thumb-2 function. mcount_adjust would > not help here since the ORing is done later, when the relocation is > applied. Hmm, from what I can make out the C version of recordmcount uses R_ARM_ABS32 as well. > Thumb-2 via recordmcount.c does not need the clearing of the lsb in > ftrace_call_adjust. So the clearing of the lsb is only required if the recordmcount.pl script is used? > Building with the ARM instruction set also does not need the clearing > of the lsb. Who does the ORing? I can't find anything in recordmount.pl/recordmcount.c which looks like doing an OR, does the assembler do that based on the symbol type? > > 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. > > To remove ftrace_call_adjust, we could either deprecate the > recordmcount.pl usage for ARM (you already have to edit the Kconfig to > use it) or modify it to generate specific relocations explicitly instead > of using the assembler data directives. Hmm, it would be a desirable property if the C version and the pearl version of recordmcount would do the same. Or we could remove the arm support from the pearl script, the C version is faster anyway. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [patch 0/4] [RFC] mcount address adjustment 2011-05-12 9:24 ` Martin Schwidefsky @ 2011-05-12 13:30 ` Rabin Vincent 2011-05-16 12:57 ` Dave Martin 0 siblings, 1 reply; 5+ messages in thread From: Rabin Vincent @ 2011-05-12 13:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 12, 2011 at 14:54, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: > On Wed, 11 May 2011 22:53:55 +0530 Rabin Vincent <rabin@rab.in> wrote: >> On Tue, May 10, 2011 at 13:40, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: >> Thumb-2 via recordmcount.pl needs the clearing of the lsb because the >> relocation (R_ARM_ABS32) that gets used for the assembly file >> that recordmcount.pl generates and assembles dictates that the lsb be >> set if the target symbol is Thumb/Thumb-2 function. ?mcount_adjust would >> not help here since the ORing is done later, when the relocation is >> applied. > > Hmm, from what I can make out the C version of recordmcount uses R_ARM_ABS32 > as well. Right. It worked when I initially implemented ARM support there because recordmcount.c always found the STT_SECTION symbol as a base and not a STT_FUNC symbol. However, I noticed yesterday that this does not happen in some cases, so I sent a patch to avoid STT_FUNC symbol as bases on ARM, not because of this relocation, but because of a slightly different oddity of Thumb symbols: http://lkml.org/lkml/2011/5/11/304 (The relocation problem alone could be solved by using R_ARM_ABS32_NOI instead.) > >> Thumb-2 via recordmcount.c does not need the clearing of the lsb in >> ftrace_call_adjust. > > So the clearing of the lsb is only required if the recordmcount.pl script > is used? Yes. >> Building with the ARM instruction set also does not need the clearing >> of the lsb. > > Who does the ORing? I can't find anything in recordmount.pl/recordmcount.c > which looks like doing an OR, does the assembler do that based on the > symbol type? The lsb is set to 1 by the linker, when it applies the relocations as it links vmlinux. > >> > 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. >> >> To remove ftrace_call_adjust, we could either deprecate the >> recordmcount.pl usage for ARM (you already have to edit the Kconfig to >> use it) or modify it to generate specific relocations explicitly instead >> of using the assembler data directives. > > Hmm, it would be a desirable property if the C version and the pearl > version of recordmcount would do the same. Or we could remove the arm > support from the pearl script, the C version is faster anyway. I'm OK with removing the ARM support from recordmcount.pl; it doesn't seem needed to make significant modifications to it for ARM when we don't use it anyway. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [patch 0/4] [RFC] mcount address adjustment 2011-05-12 13:30 ` Rabin Vincent @ 2011-05-16 12:57 ` Dave Martin 2011-05-16 14:28 ` Steven Rostedt 0 siblings, 1 reply; 5+ messages in thread From: Dave Martin @ 2011-05-16 12:57 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 12, 2011 at 07:00:13PM +0530, Rabin Vincent wrote: > On Thu, May 12, 2011 at 14:54, Martin Schwidefsky > <schwidefsky@de.ibm.com> wrote: > > On Wed, 11 May 2011 22:53:55 +0530 Rabin Vincent <rabin@rab.in> wrote: > >> On Tue, May 10, 2011 at 13:40, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote: > >> Thumb-2 via recordmcount.pl needs the clearing of the lsb because the > >> relocation (R_ARM_ABS32) that gets used for the assembly file > >> that recordmcount.pl generates and assembles dictates that the lsb be > >> set if the target symbol is Thumb/Thumb-2 function. ?mcount_adjust would > >> not help here since the ORing is done later, when the relocation is > >> applied. > > > > Hmm, from what I can make out the C version of recordmcount uses R_ARM_ABS32 > > as well. > > Right. It worked when I initially implemented ARM support there because > recordmcount.c always found the STT_SECTION symbol as a base and not a > STT_FUNC symbol. However, I noticed yesterday that this does not happen > in some cases, so I sent a patch to avoid STT_FUNC symbol as bases on > ARM, not because of this relocation, but because of a slightly different > oddity of Thumb symbols: > > http://lkml.org/lkml/2011/5/11/304 > > (The relocation problem alone could be solved by using R_ARM_ABS32_NOI > instead.) > > > > >> Thumb-2 via recordmcount.c does not need the clearing of the lsb in > >> ftrace_call_adjust. > > > > So the clearing of the lsb is only required if the recordmcount.pl script > > is used? > > Yes. > > >> Building with the ARM instruction set also does not need the clearing > >> of the lsb. > > > > Who does the ORing? I can't find anything in recordmount.pl/recordmcount.c > > which looks like doing an OR, does the assembler do that based on the > > symbol type? > > The lsb is set to 1 by the linker, when it applies the relocations as it > links vmlinux. > > > > >> > 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. > >> > >> To remove ftrace_call_adjust, we could either deprecate the > >> recordmcount.pl usage for ARM (you already have to edit the Kconfig to > >> use it) or modify it to generate specific relocations explicitly instead > >> of using the assembler data directives. > > > > Hmm, it would be a desirable property if the C version and the pearl > > version of recordmcount would do the same. Or we could remove the arm > > support from the pearl script, the C version is faster anyway. > > I'm OK with removing the ARM support from recordmcount.pl; it doesn't > seem needed to make significant modifications to it for ARM when we > don't use it anyway. Is there any reason why the recordmcount.pl would ever be used now that the C implementation exists? I notice that arch/arm/Kconfig has: config ARM ... select HAVE_C_RECORDMCOUNT so deprecating ARM support from recordmcount.pl seems unlikely to hurt anyone. The C implementation seems to have worked fine when I was testing dynamic ftrace with Thumb-2 recently. Cheers ---Dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* [patch 0/4] [RFC] mcount address adjustment 2011-05-16 12:57 ` Dave Martin @ 2011-05-16 14:28 ` Steven Rostedt 0 siblings, 0 replies; 5+ messages in thread From: Steven Rostedt @ 2011-05-16 14:28 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2011-05-16 at 13:57 +0100, Dave Martin wrote: > Is there any reason why the recordmcount.pl would ever be used now that the > C implementation exists? > > I notice that arch/arm/Kconfig has: > > config ARM > ... > select HAVE_C_RECORDMCOUNT > > so deprecating ARM support from recordmcount.pl seems unlikely to hurt > anyone. > > The C implementation seems to have worked fine when I was testing dynamic > ftrace with Thumb-2 recently. It's there only as a backup. But you're right. I may as well start removing the recordmcount.pl support from those that have the HAVE_C_RECORDMCOUNT set, and then all users are gone (which may now be the case) either keep it around as a backup for testing against recordmcount.c, or remove it completely. -- Steve ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-05-16 14:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20110510081039.241831019@de.ibm.com>
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
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).