Eric Lee / smarc-fsl-linux-kernel

17 May, 2011

3 commits

10 Mar, 2011

1 commit

02 Sep, 2010

2 commits

  • 72dc43a9e   ARM: 6319/1: ftrace: add Thumb-2 support to dynamic ftrace ... Browse Code »

    Handle the different nop and call instructions for Thumb-2. Also, we
    need to adjust the recorded mcount_loc addresses because they have the
    lsb set.

    Cc: Catalin Marinas
    Acked-by: Steven Rostedt [recordmcount.pl change]
    Signed-off-by: Rabin Vincent
    Signed-off-by: Russell King

    Rabin Vincent
     
  • 3b6c223b1   ARM: 6318/1: ftrace: fix and update dynamic ftrace ... Browse Code »

    This adds mcount recording and updates dynamic ftrace for ARM to work
    with the new ftrace dyamic tracing implementation. It also adds support
    for the mcount format used by newer ARM compilers.

    With dynamic tracing, mcount() is implemented as a nop. Callsites are
    patched on startup with nops, and dynamically patched to call to the
    ftrace_caller() routine as needed.

    Acked-by: Steven Rostedt [recordmcount.pl change]
    Signed-off-by: Rabin Vincent
    Signed-off-by: Russell King

    Rabin Vincent
     

16 Aug, 2010

1 commit

12 Aug, 2010

1 commit

23 Jul, 2010

1 commit

  • a484e54fa   tracing: Fix $mcount_regex for MIPS in recordmcount.pl ... Browse Code »

    I found this issue in a locally patched 2.6.32.x, current kernels have
    moved the offending code to an __init function which is skipped by
    recordmcount.pl, so the bug is not currently being exercised.
    However, I think the patch is still a good idea, to avoid future
    problems if _mcount were to ever have its address taken in normal
    code.

    This is what I originally saw:

    Although arch/mips/kernel/ftrace.c is built without -pg, and thus
    contains no calls to _mcount, it does use the address of _mcount
    in ftrace_make_nop(). This was causing relocations to be emitted
    for _mcount which recordmcount.pl erronously took to be _mcount
    call sites. The result was that the text of ftrace_make_nop()
    would be patched with garbage leading to a system crash.

    In non-module code, all _mcount call sites will have R_MIPS_26
    relocations, so we restrict $mcount_regex to only match on these.

    Acked-by: Ralf Baechle
    Acked-by: Wu Zhangjin
    Signed-off-by: David Daney
    LKML-Reference:
    Cc: Li Hong
    Cc: Ingo Molnar
    Cc: Matt Fleming
    Signed-off-by: Steven Rostedt

    David Daney
     

26 Feb, 2010

1 commit

12 Jan, 2010

1 commit

07 Jan, 2010

2 commits

17 Dec, 2009

2 commits

  • 538f19526   MIPS: Tracing: Add dynamic function tracer support ... Browse Code »

    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 -v4 version, the implementation of this support is basically the same as
    X86 version does: _mcount is implemented as an empty function and ftrace_caller
    is implemented as a real tracing function respectively.

    But in this version, to support module tracing with the help of
    -mlong-calls in arch/mips/Makefile:

    MODFLAGS += -mlong-calls.

    The stuff becomes a little more complex. We need to cope with two
    different type of calling to _mcount.

    For the kernel part, the calling to _mcount(result of "objdump -hdr
    vmlinux"). is like this:

    108: 03e0082d move at,ra
    10c: 0c000000 jal 0
    10c: R_MIPS_26 _mcount
    10c: R_MIPS_NONE *ABS*
    10c: R_MIPS_NONE *ABS*
    110: 00020021 nop

    For the module with -mlong-calls, it looks like this:

    c: 3c030000 lui v1,0x0
    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

    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, but in the module version, we need to choose
    one of the two to match. Herein, I choose the first one with
    "R_MIPS_HI16 _mcount".

    and In the kernel verion, without module tracing support, we just need
    to replace "jal _mcount" by "jal ftrace_caller" to do real tracing, and
    filter the tracing of some kernel functions via replacing it by a nop
    instruction.

    but as we have described before, the instruction "jal ftrace_caller" only left
    32bit length for the address of ftrace_caller, it will fail when calling from
    the module space. so, herein, we must replace something else.

    the basic idea is loading the address of ftrace_caller to v1 via changing these
    two instructions:

    lui v1,0x0
    addiu v1,v1,0

    If we want to enable the tracing, we need to replace the above instructions to:

    lui v1, HI_16BIT_ftrace_caller
    addiu v1, v1, LOW_16BIT_ftrace_caller

    If we want to stop the tracing of the indicated kernel functions, we
    just need to replace the "jalr v1" to a nop instruction. but we need to
    replace two instructions and encode the above two instructions
    oursevles.

    Is there a simpler solution? Yes! Here it is, in this version, we put _mcount
    and ftrace_caller together, which means the address of _mcount and
    ftrace_caller is the same:

    _mcount:
    ftrace_caller:
    j ftrace_stub
    nop

    ...(do real tracing here)...

    ftrace_stub:
    jr ra
    move ra, at

    By default, the kernel functions call _mcount, and then jump to ftrace_stub and
    return. and when we want to do real tracing, we just need to remove that "j
    ftrace_stub", and it will run through the two "nop" instructions and then do
    the real tracing job.

    what about filtering job? we just need to do this:

    lui v1, hi_16bit_of_mcount b 1f (0x10000004)
    addiu v1, v1, low_16bit_of_mcount
    move at, ra
    jalr v1
    nop
    1f: (rec->ip + 12)

    In linux-mips64, there will be some local symbols, whose name are
    prefixed by $L, which need to be filtered. thanks goes to Steven for
    writing the mips64-specific function_regex.

    In a conclusion, with RISC, things becomes easier with such a "stupid"
    trick, RISC is something like K.I.S.S, and also, there are lots of
    "simple" tricks in the whole ftrace support, thanks goes to Steven and
    the other folks for providing such a wonderful tracing framework!

    Signed-off-by: Wu Zhangjin
    Cc: Nicholas Mc Guire
    Cc: zhangfx@lemote.com
    Cc: Wu Zhangjin
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Frederic Weisbecker
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: http://patchwork.linux-mips.org/patch/675/
    Acked-by: Steven Rostedt
    Signed-off-by: Ralf Baechle

    Wu Zhangjin
     
  • e6299d267   MIPS: Tracing: Add an endian argument to scripts/recordmcount.pl ... Browse Code »

    MIPS and some other architectures need this argument to handle
    big/little endian respectively.

    Signed-off-by: Wu Zhangjin
    Cc: Nicholas Mc Guire
    Cc: zhangfx@lemote.com
    Cc: Wu Zhangjin
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Frederic Weisbecker
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: http://patchwork.linux-mips.org/patch/674/
    Acked-by: Steven Rostedt
    Signed-off-by: Ralf Baechle

    Wu Zhangjin
     

14 Dec, 2009

1 commit

  • 7d241ff05   microblaze: ftrace: Add dynamic trace support ... Browse Code »

    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: Steven Rostedt
    Signed-off-by: Michal Simek

    Michal Simek
     

18 Nov, 2009

1 commit

  • 638adb056   tracing: Only print objcopy version warning once from recordmcount ... Browse Code »

    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: Andrew Morton
    Cc: Sam Ravnborg
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

30 Oct, 2009

8 commits

14 Oct, 2009

1 commit

  • 4d8289494   tracing: Enable "__cold" functions ... Browse Code »

    Based on the commit:

    a586df06 "x86: Support __attribute__((__cold__)) in gcc 4.3"

    some of the functions goes to the ".text.unlikely" section.

    Looks like there's not many of them (I found printk, panic,
    __ssb_dma_not_implemented, fat_fs_error), but still worth to
    include I think.

    Signed-off-by: Jiri Olsa
    Cc: Frederic Weisbecker
    Signed-off-by: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jiri Olsa
     

11 Aug, 2009

1 commit

07 Aug, 2009

1 commit

  • 7dbdee2e9   tracing: Fix recordmcount.pl to handle sections with only weak functions ... Browse Code »

    Roland Dreier found that a section that contained only a weak
    function in one of the staging drivers and this caused
    recordmcount.pl to spit out a warning and fail.

    Although it is strange that a driver would have a weak function, and
    this function only be used in one place, it should not be something
    to make recordmcount.pl fail.

    This patch fixes the issue in a simple manner: if only weak
    functions exist in a section, then that section will not be
    recorded.

    Reported-by: Roland Dreier
    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Steven Rostedt
     

06 Aug, 2009

1 commit

  • 3f6e968ef   tracing: do not use functions starting with .L in recordmcount.pl ... Browse Code »

    On Wed, 5 Aug 2009, Ingo Molnar wrote:
    > * Dave Airlie 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 :
    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: Dave Airlie
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

24 Jul, 2009

2 commits

  • bd171d5ff   ftrace: Only update $offset when we update $ref_func ... Browse Code »

    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: Matt Fleming
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Matt Fleming
     
  • fc4c73554   ftrace: Fix the conditional that updates $ref_func ... Browse Code »

    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: Matt Fleming
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Matt Fleming
     

18 Jul, 2009

1 commit

16 Jun, 2009

1 commit

12 Jun, 2009

1 commit

06 May, 2009

1 commit

  • 31b6e76e2   ftrace: use .sched.text, not .text.sched in recordmcount.pl ... Browse Code »

    The only references in the kernel to the .text.sched section are in
    recordmcount.pl. Since the code it has is intended to be example code
    it should refer to real kernel sections. So change it to .sched.text
    instead.

    [ Impact: consistency in comments ]

    Signed-off-by: Tim Abbott
    LKML-Reference:
    Acked-by: Sam Ravnborg
    Signed-off-by: Steven Rostedt

    Tim Abbott
     

19 Jan, 2009

1 commit

  • b43f70933   ftrace: test for running of recordmcount.pl twice on an object ... Browse Code »

    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 [] 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: Eric Sesterhenn
    Reported-by: Eric Paris
    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Steven Rostedt
     

14 Jan, 2009

3 commits

12 Dec, 2008

1 commit

  • a0343e823   tracing/function-graph-tracer: add a new .irqentry.text section ... Browse Code »

    Impact: let the function-graph-tracer be aware of the irq entrypoints

    Add a new .irqentry.text section to store the irq entrypoints functions
    inside the same section. This way, the tracer will be able to signal
    an interrupts triggering on output by recognizing these entrypoints.

    Also, make this section recordable for dynamic tracing.

    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker