Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 12月, 2009 1 次提交
  3. 14 12月, 2009 1 次提交
    • M
      microblaze: ftrace: Add dynamic trace support · 7d241ff0
      由 Michal Simek 提交于 
      With dynamic function tracer, by default, _mcount is defined as an
"empty" function, it returns directly without any more action. When
enabling it in user-space, it will jump to a real tracing
function(ftrace_caller), and do the real job for us.

Differ from the static function tracer, dynamic function tracer provides
two functions ftrace_make_call()/ftrace_make_nop() to enable/disable the
tracing of some indicated kernel functions(set_ftrace_filter).

In the kernel version, there is only one "_mcount" string for every
kernel function, so, we just need to match this one in mcount_regex of
scripts/recordmcount.pl.

For more information please look at code and Documentation/trace folder.

Steven ACK that scripts/recordmcount.pl part.
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NMichal Simek <monstr@monstr.eu>
      7d241ff0
  5. 18 11月, 2009 1 次提交
    • S
      tracing: Only print objcopy version warning once from recordmcount · 638adb05
      由 Steven Rostedt 提交于 
      If the user has an older version of objcopy, that can not handle
converting local symbols to global and vice versa, then some
functions will not be part of the dynamic function tracer. The current
code in recordmcount.pl will print a warning in this case. Unfortunately,
there exists lots of files that may have this issue with older objcopys
and this will cause a warning for every file compiled with this
issue.

This patch solves this overwhelming output by creating a
.tmp_quiet_recordmcount file on the first instance the warning is
encountered. The warning will not print if this file exists.

The temp file is deleted at the beginning of the compile to ensure that
the warning will happen once again on new compiles (because the issue
is still present).
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      638adb05
  7. 30 10月, 2009 8 次提交
  9. 14 10月, 2009 1 次提交
  11. 07 8月, 2009 1 次提交
  13. 06 8月, 2009 1 次提交
    • S
      tracing: do not use functions starting with .L in recordmcount.pl · 3f6e968e
      由 Steven Rostedt 提交于 
      On Wed, 5 Aug 2009, Ingo Molnar wrote:
> * Dave Airlie <airlied@gmail.com> wrote:
>
> > Hey,
> >
> > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o
> > breakage by blaming rawhide gcc/binutils as I was using make
> > V=1and seeing only the compiler chain running,
>
> Hm, is this that powerpc related build bug you just reported?

Well we tracked it down and it is powerpc64 specific.

Seems that in drivers/hwmon/lm93.c there's a function called:

   LM93_IN_FROM_REG()

But PPC64 has function descriptors and the real function names (the ones
you see in objdump) start with a '.'. Thus this in objdump you have:

 Disassembly of section .text:

 0000000000000000 <.LM93_IN_FROM_REG>:
       0:       7c 08 02 a6     mflr    r0
       4:       fb 81 ff e0     std     r28,-32(r1)

The function name used is .LM93_IN_FROM_REG. But gcc considers symbols
that start with ".L" as a special symbol that is used inside the assembly
stage.

The nm passed into recordmcount uses the --synthetic option which shows
the ".L" symbols (my runs outside of the build did not include the
--synthetic option, so my older patch worked). We see the function as a
local.

Now to capture all the locations that use "mcount" we need to have a
reference to link into the object file a list of mcount callers. We need a
reference that will not disappear. We try to use a global function and if
that does not work, we use a local function as a reference. But to relink
the section back into the object, we need to make it global. In this case,
we run objcopy using --globalize-symbol and --localize-symbol to convert
the symbol into a global symbol, link the mcount list, then convert it
back to a local symbol.

This works great except for this case. .L* symbols can not be converted
into a global symbol, and the mcount section referencing it will remain
unresolved.
Reported-by: NDave Airlie <airlied@gmail.com>
LKML-Reference: <alpine.DEB.2.00.0908052011590.5010@gandalf.stny.rr.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      3f6e968e
  15. 24 7月, 2009 2 次提交
    • M
      ftrace: Only update $offset when we update $ref_func · bd171d5f
      由 Matt Fleming 提交于 
      The value of $offset should be the offset of $ref_func from the
beginning of the object file. Therefore, we should set both variables
together.

This fixes a bug I was hitting on sh where $offset (which is used to
calcualte the addends for the __mcount_loc entries) was being set
multiple times and didn't correspond to $ref_func's offset in the object
file. The addends in __mcount_loc were calculated incorrectly, resulting
in ftrace dynamically modifying addresses that weren't mcount call
sites.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
LKML-Reference: <1248365775-25196-2-git-send-email-matt@console-pimps.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      bd171d5f
    • M
      ftrace: Fix the conditional that updates $ref_func · fc4c7355
      由 Matt Fleming 提交于 
      Fix the conditional that checks if we already have a $ref_func and that
the new function is weak. The code as previously checking whether either
condition was false, and we really need to only update $ref_func is both
cconditions are false.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
LKML-Reference: <1248365775-25196-1-git-send-email-matt@console-pimps.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      fc4c7355
  17. 18 7月, 2009 1 次提交
  19. 16 6月, 2009 1 次提交
  21. 12 6月, 2009 1 次提交
  23. 06 5月, 2009 1 次提交
  25. 19 1月, 2009 1 次提交
    • S
      ftrace: test for running of recordmcount.pl twice on an object · b43f7093
      由 Steven Rostedt 提交于 
      Impact: fix failure of dynamic function tracer selftest

In a course of development, a developer does several makes on their
kernel. Sometimes, the make might do something abnormal. In the
case of running the recordmcount.pl script on an object twice,
the script will duplicate all the calls to mcount in the __mcount_loc
section.

On boot up, the dynamic function tracer is careful when it modifies
code, and performs several consistency checks. One is to not modify
the call site if it is not what it expects it to be. If a function
call site is listed twice, the first entry will convert the site
to a nop, and the second will fail because it expected to see a
call to mcount, but instead it sees a nop. Thus, the function tracer
is disabled.

Eric Sesterhenn reported seeing:

[    1.055440] ftrace: converting mcount calls to 0f 1f 44 00 00
[    1.055568] ftrace: allocating 29418 entries in 116 pages
[    1.061000] ------------[ cut here ]------------
[    1.061000] WARNING: at kernel/trace/ftrace.c:441

 [...]

[    1.060000] ---[ end trace 4eaa2a86a8e2da23 ]---
[    1.060000] ftrace failed to modify [<c0118072>] check_corruption+0x3/0x2d
[    1.060000]  actual: 0f:1f:44:00:00

This warning shows that check_corruption+0x3 already had a nop in
its place (0x0f1f440000). After compiling another kernel the problem
went away.

Later Eric Paris notice the same type of issue. Luckily, he saved
the vmlinux file that caused it. In the file we found a bunch of
duplicate mcount call site records, which lead us to the script.

Perhaps this problem only happens to people named Eric.

This patch changes the script to test if the __mcount_loc already
exists in the object file, and if it does, it will print out
an error message and kill the compile.
Reported-by: NEric Sesterhenn <snakebyte@gmx.de>
Reported-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b43f7093
  27. 14 1月, 2009 3 次提交
  29. 22 12月, 2008 1 次提交
  31. 12 12月, 2008 1 次提交
  33. 26 11月, 2008 1 次提交
  35. 23 11月, 2008 5 次提交
  37. 08 11月, 2008 1 次提交
  39. 23 10月, 2008 2 次提交
  41. 14 10月, 2008 5 次提交
    • S
      ftrace: remove warning of old objcopy and local functions · d53475b5
      由 Steven Rostedt 提交于 
      The warning messages about old objcopy and local functions spam the
user quite drastically.  Remove the warning until we can find a nicer
way of tell the user to upgrade their objcopy.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d53475b5
    • S
      ftrace: objcopy version test for local symbols · f2f8458e
      由 Steven Rostedt 提交于 
      The --globalize-symbols option came out in objcopy version 2.17.
If the kernel is being compiled on a system with a lower version of
objcopy, then we can not use the globalize / localize trick to
link to symbols pointing to local functions.

This patch tests the version of objcopy and will only use the trick
if the version is greater than or equal to 2.17. Otherwise, if an
object has only local functions within a section, it will give a
nice warning and recommend the user to upgrade their objcopy.

Leaving the symbols unrecorded is not that big of a deal, since the
mcount record method changes the actual mcount code to be a simple
"ret" without recording registers or anything.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f2f8458e
    • S
      ftrace: handle weak symbol functions · 8feff1ca
      由 Steven Rostedt 提交于 
      During tests and checks, I've discovered that there were failures to
convert mcount callers into nops. Looking deeper into these failures,
code that was attempted to be changed was not an mcount caller.
The current code only updates if the code being changed is what it expects,
but I still investigate any time there is a failure.

What was happening is that a weak symbol was being used as a reference
for other mcount callers. That weak symbol was also referenced elsewhere
so the offsets were using the strong symbol and not the function symbol
that it was referenced from.

This patch changes the setting up of the mcount_loc section to search
for a global function that is not weak. It will pick a local over a weak
but if only a weak is found in a section, a warning is printed and the
mcount location is not recorded (just to be safe).
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8feff1ca
    • S
      ftrace: update recordmount.pl arch changes · d74fcd1e
      由 Steven Rostedt 提交于 
      I'm trying to keep all the arch changes in recordmcount.pl in one place.
I moved your code into that area, by adding the flags to the commands
that were passed in.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d74fcd1e
    • I
      ftrace: scripts/recordmcount.pl cross-build hack · 3989cce8
      由 Ingo Molnar 提交于 
      hack around:

 ld: Relocatable linking with relocations from format elf32-i386 (init/.tmp_gl_calibrate.o) to format elf64-x86-64 (init/.tmp_mx_calibrate.o) i  CC      arch/x86/mm/extable.o
 objcopy: 'init/.tmp_mx_calibrate.o': No such file
 rm: cannot remove `init/.tmp_mx_calibrate.o': No such file or directory
 ld: Relocatable linking with relocations from format elf32-i386 (arch/x86/mm/extable.o) to format elf64-x86-64 (arch/x86/mm/.tmp_mx_extable.o) is not supported
 mv: cannot stat `arch/x86/mm/.tmp_mx_extable.o': No such file or directory
 ld: Relocatable linking with relocations from format elf32-i386 (arch/x86/mm/fault.o) to format elf64-x86-64 (arch/x86/mm/.tmp_mx_fault.o) is not supported
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3989cce8