summaryrefslogtreecommitdiffstats
path: root/scripts/recordmcount.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* recordmcount: Fix endianness handling bug for nop_mcountlibin2015-11-031-1/+1
| | | | | | | | | | | | In nop_mcount, shdr->sh_offset and welp->r_offset should handle endianness properly, otherwise it will trigger Segmentation fault if the recordmcount main and file.o have different endianness. Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com Cc: <stable@vger.kernel.org> # 3.0+ Signed-off-by: Li Bin <huawei.libin@huawei.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modulesAlex Smith2014-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On MIPS calls to _mcount in modules generate 2 instructions to load the _mcount address (and therefore 2 relocations). The mcount_loc table should only reference the first of these, so the second is filtered out by checking the relocation offset and ignoring ones that immediately follow the previous one seen. However if a module has an _mcount call at offset 0, the second relocation would not be filtered out due to old_r_offset == 0 being taken to mean that the current relocation is the first one seen, and both would end up in the mcount_loc table. This results in ftrace_make_nop() patching both (adjacent) instructions to branches over the _mcount call sequence like so: 0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014 0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018 0xffffffffc08a8008: 2d 08 e0 03 move at,ra ... The second branch is in the delay slot of the first, which is defined to be unpredictable - on the platform on which this bug was encountered, it triggers a reserved instruction exception. Fix by initializing old_r_offset to ~0 and using that instead of 0 to determine whether the current relocation is the first seen. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7098/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* ftrace: Make recordmcount.c handle __fentry__Steven Rostedt2012-08-231-1/+3
| | | | | | | | | | | | | | | | | With gcc 4.6.0 the -mfentry feature places the function profiling call at the start of the function. When this is used, the call is to __fentry__ and not mcount. Change recordmcount.c to record both callers to __fentry__ and mcount. Link: http://lkml.kernel.org/r/20120807194058.990674363@goodmis.org Acked-by: H. Peter Anvin <hpa@linux.intel.com> Acked-by: John Reiser <jreiser@bitwagon.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* recordmcount: Fix handling of elf64 big-endian objects.David Daney2012-01-061-1/+1
| | | | | | | | | | | | | | | | | | | | | In ELF64, the sh_flags field is 64-bits wide. recordmcount was erroneously treating it as a 32-bit wide field. For little endian objects this works because the flags of interest (SHF_EXECINSTR) reside in the lower 32 bits of the word, and you get the same result with either a 32-bit or 64-bit read. Big endian objects on the other hand do not work at all with this error. The fix: Correctly treat sh_flags as 64-bits wide in elf64 objects. The symptom I observed was that my __start_mcount_loc..__stop_mcount_loc was empty even though ftrace function tracing was enabled. Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.com Cc: stable@kernel.org # 3.0+ Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Avoid STT_FUNC symbols as base on ARMRabin Vincent2011-05-261-0/+8
| | | | | | | | | | | | | | | | | | | While find_secsym_ndx often finds the unamed local STT_SECTION, if a section has only one function in it, the ARM toolchain generates the STT_FUNC symbol before the STT_SECTION, and recordmcount finds this instead. This is problematic on ARM because in ARM ELFs, "if a [STT_FUNC] symbol addresses a Thumb instruction, its value is the address of the instruction with bit zero set (in a relocatable object, the section offset with bit zero set)". This leads to incorrect mcount addresses being recorded. Fix this by not using STT_FUNC symbols as the base on ARM. Signed-off-by: Rabin Vincent <rabin@rab.in> Link: http://lkml.kernel.org/r/1305134631-31617-1-git-send-email-rabin@rab.in Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: mcount address adjustmentMartin Schwidefsky2011-05-161-2/+7
| | | | | | | | | | | | | Introduce mcount_adjust{,_32,_64} to the C implementation of recordmcount analog to $mcount_adjust in the perl script. The adjustment is added to the address of the relocations against the mcount symbol. If this adjustment is done by recordmcount at compile time the ftrace_call_adjust function can be turned into a nop. Cc: John Reiser <jreiser@bitwagon.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Add helper function get_sym_str_and_relp()Steven Rostedt2011-05-161-30/+37
| | | | | | | | | | | The code to get the symbol, string, and relp pointers in the two functions sift_rel_mcount() and nop_mcount() are identical and also non-trivial. Moving this duplicate code into a single helper function makes the code easier to read and more maintainable. Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023739.723658553@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Remove duplicate code to find mcount symbolSteven Rostedt2011-05-161-24/+27
| | | | | | | | | | The code in sift_rel_mcount() and nop_mcount() to get the mcount symbol number is identical. Replace the two locations with a call to a function that does the work. Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023739.488093407@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Add warning logic to warn on mcount not recordedSteven Rostedt2011-05-161-5/+17
| | | | | | | | | | | | | | | | There's some sections that should not have mcount recorded and should not have modifications to the that code. But currently they waste some time by calling mcount anyway (which simply returns). As the real answer should be to either whitelist the section or have gcc ignore it fully. This change adds a option to recordmcount to warn when it finds a section that is ignored by ftrace but still contains mcount callers. This is not on by default as developers may not know if the section should be completely ignored or added to the whitelist. Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023738.476989377@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Make ignored mcount calls into nops at compile timeSteven Rostedt2011-05-161-4/+78
| | | | | | | | | | | | | | | | | | | | | | | There are sections that are ignored by ftrace for the function tracing because the text is in a section that can be removed without notice. The mcount calls in these sections are ignored and ftrace never sees them. The downside of this is that the functions in these sections still call mcount. Although the mcount function is defined in assembly simply as a return, this added overhead is unnecessary. The solution is to convert these callers into nops at compile time. A better solution is to add 'notrace' to the section markers, but as new sections come up all the time, it would be nice that they are delt with when they are created. Later patches will deal with finding these sections and doing the proper solution. Thanks to H. Peter Anvin for giving me the right nops to use for x86. Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023738.237101176@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/recordmcount: Modify only executable sectionsSteven Rostedt2011-05-161-0/+1
| | | | | | | | | PROGBITS is not enough to determine if the section should be modified or not. Only process sections that are marked as executable. Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023737.991485123@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/trivial: Clean up recordmcount.c to use Linux style comparisonsSteven Rostedt2011-05-161-8/+8
| | | | | | | | | | | | | | | | | | | | | | The Linux ftrace subsystem style for comparing is: var == 1 var > 0 and not: 1 == var 0 < var It is considered that Linux developers are smart enough not to do the if (var = 1) mistake. Cc: John Reiser <jreiser@bitwagon.com> Link: http://lkml.kernel.org/r/20110421023737.290712238@goodmis.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
*-. Merge branches 'ftrace', 'gic', 'io', 'kexec', 'mod', 'sa11x0', 'sh' and ↵Russell King2011-01-051-2/+3
|\ \ | | | | | | | | | 'versatile' into devel
| * | ARM: 6511/1: ftrace: add ARM support for C version of recordmcountRabin Vincent2010-12-041-2/+3
| |/ | | | | | | | | | | | | | | | | Depending on the compiler version, ARM GCC calls the mcount function either __gnu_mcount_nc or mcount. Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* / ftrace: Have recordmcount honor endianness in fn_ELF_R_INFOJohn Reiser2010-12-021-1/+1
|/ | | | | | | | | | | | | | | | It looks to me like the change which introduced "virtual functions" forgot about cross-platform endianness. Thank you to Arnaud for supplying before+after data files do_mounts*.o. This fixes a MIPS build failure triggered by recordmcount. Reported-by: Arnaud Lacombe <lacombar@gmail.com> Tested-by: Arnaud Lacombe <lacombar@gmail.com> Acked-by: Wu Zhangjin <wuzhangjin@gmail.com> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John Reiser <jreiser@BitWagon.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* ftrace/MIPS: Add module support for C version of recordmcountWu Zhangjin2010-10-291-3/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since MIPS modules' address space differs from the core kernel space, to access the _mcount in the core kernel, the kernel functions in modules must use long call (-mlong-calls): load the _mcount address into one register and jump to the address stored by the register: c: 3c030000 lui v1,0x0 <--------> b label c: R_MIPS_HI16 _mcount c: R_MIPS_NONE *ABS* c: R_MIPS_NONE *ABS* 10: 64630000 daddiu v1,v1,0 10: R_MIPS_LO16 _mcount 10: R_MIPS_NONE *ABS* 10: R_MIPS_NONE *ABS* 14: 03e0082d move at,ra 18: 0060f809 jalr v1 label: In the old Perl version of recordmcount, we only need to record the position of the 1st R_MIPS_HI16 type of _mcount, and later, in ftrace_make_nop(), replace the instruction in this position by a "b label" and in ftrace_make_call(), replace it back. But, the default C version of recordmcount records all of the _mcount symbols, so, we must filter the 2nd _mcount like the Perl version of recordmcount does. The C version of recordmcount copes with the symbols before they are linked, So It doesn't know the type of the symbols and therefore can not filter the symbols as the Perl version of recordmcount does. But as we can see above, the 2nd _mcount symbols of the long call alawys follows the 1st _mcount symbol of the same long call, which means the offset from the 1st to the 2nd is fixed, it is 0x10-0xc = 4 here, 4 is the length of the 1st load instruciton, for MIPS has fixed length of instructions, this offset is always 4. And as we know, the _mcount is inserted into the entry of every kernel function, the offset between the other _mcount's is expected to be always bigger than 4. So, to filter the 2ns _mcount symbol of the long call, we can simply check the offset between two _mcount symbols, If it is 4, then, filter the 2nd _mcount symbol. To avoid touching too much code, an 'empty' function fn_is_fake_mcount() is added for all of the archs, and the specific archs can override it via chaning the function pointer: is_fake_mcount in do_file() with the e_machine. e.g. This patch adds MIPS_is_fake_mcount() to override the default fn_is_fake_mcount() pointed by is_fake_mcount. This fn_is_fake_mcount() checks if the _mcount symbol is fake, e.g. the 2nd _mcount symbol of the long call is fake, for there are 2 _mcount symbols mapped to one real mcount call, so, one of them is fake and must be filtered. This fn_is_fake_mcount() is called in sift_rel_mcount() after finding the _mcount symbols and before adding the _mcount symbol into mrelp, so, it can prevent the fake mcount symbol going into the last __mcount_loc table. Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> LKML-Reference: <b866f0138224340a132d31861fa3f9300dee30ac.1288176026.git.wuzhangjin@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* ftrace/MIPS: Add MIPS64 support for C version of recordmcountJohn Reiser2010-10-291-4/+30
| | | | | | | | | | | | | | | | | | | | | MIPS64 has 'weird' Elf64_Rel.r_info[1,2], which must be used instead of the generic Elf64_Rel.r_info, otherwise, the C version of recordmcount will not work for "segmentation fault". Usage of "union mips_r_info" and the functions MIPS64_r_sym() and MIPS64_r_info() written by Maciej W. Rozycki <macro@linux-mips.org> ---- [1] http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf [2] arch/mips/include/asm/module.h Tested-by: Wu Zhangjin <wuzhangjin@gmail.com> Signed-off-by: John Reiser <jreiser@BitWagon.com> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> LKML-Reference: <AANLkTinwXjLAYACUfhLYaocHD_vBbiErLN3NjwN8JqSy@mail.gmail.com> LKML-Reference: <910dc2d5ae1ed042df4f96815fe4a433078d1c2a.1288176026.git.wuzhangjin@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* ftrace: Remove duplicate code for 64 and 32 bit in recordmcount.cSteven Rostedt2010-10-141-0/+366
The elf reader for recordmcount.c had duplicate functions for both 32 bit and 64 bit elf handling. This was due to the need of using the 32 and 64 bit elf structures. This patch consolidates the two by using macros to define the 32 and 64 bit names in a recordmcount.h file, and then by just defining a RECORD_MCOUNT_64 macro and including recordmcount.h twice we create the funtions for both the 32 bit version as well as the 64 bit version using one code source. Cc: John Reiser <jreiser@bitwagon.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>