19 Nov, 2018

1 commit


06 Jun, 2018

1 commit

  • Commit 6870c0165feaa5 ("scripts/faddr2line: show the code context")
    radically altered the output format of the faddr2line tool. And while
    the new list output format might have merit it broke my vim usage and
    was hard to read.

    Make the new format optional; using a '--list' argument and attempt to
    make the output slightly easier to read by adding a little whitespace to
    separate the different files and explicitly mark the line in question.

    Cc: Changbin Du
    Fixes: 6870c0165feaa5 ("scripts/faddr2line: show the code context")
    Signed-off-by: Peter Zijlstra (Intel)
    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Linus Torvalds

    Peter Zijlstra (Intel)
     

12 May, 2018

1 commit

  • When addr2line output contains discriminator, the current awk script
    cannot parse it. This patch fixes it by extracting key words using
    regex which is more reliable.

    $ scripts/faddr2line vmlinux tlb_flush_mmu_free+0x26
    tlb_flush_mmu_free+0x26/0x50:
    tlb_flush_mmu_free at mm/memory.c:258 (discriminator 3)
    scripts/faddr2line: eval: line 173: unexpected EOF while looking for matching `)'

    Link: http://lkml.kernel.org/r/1525323379-25193-1-git-send-email-changbin.du@intel.com
    Fixes: 6870c0165feaa5 ("scripts/faddr2line: show the code context")
    Signed-off-by: Changbin Du
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Philippe Ombredanne
    Cc: NeilBrown
    Cc: Richard Weinberger
    Cc: Kate Stewart
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Changbin Du
     

06 Apr, 2018

1 commit

  • Inspired by gdb command 'list', show the code context of target lines.
    Here is a example:

    $ scripts/faddr2line vmlinux native_write_msr+0x6
    native_write_msr+0x6/0x20:
    arch_static_branch at arch/x86/include/asm/msr.h:105
    100 return EAX_EDX_VAL(val, low, high);
    101 }
    102
    103 static inline void notrace __wrmsr(unsigned int msr, u32 low, u32 high)
    104 {
    105 asm volatile("1: wrmsr\n"
    106 "2:\n"
    107 _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
    108 : : "c" (msr), "a"(low), "d" (high) : "memory");
    109 }
    110
    (inlined by) static_key_false at include/linux/jump_label.h:142
    137 #define JUMP_TYPE_LINKED 2UL
    138 #define JUMP_TYPE_MASK 3UL
    139
    140 static __always_inline bool static_key_false(struct static_key *key)
    141 {
    142 return arch_static_branch(key, false);
    143 }
    144
    145 static __always_inline bool static_key_true(struct static_key *key)
    146 {
    147 return !arch_static_branch(key, true);
    (inlined by) native_write_msr at arch/x86/include/asm/msr.h:150
    145 static inline void notrace
    146 native_write_msr(unsigned int msr, u32 low, u32 high)
    147 {
    148 __wrmsr(msr, low, high);
    149
    150 if (msr_tracepoint_active(__tracepoint_write_msr))
    151 do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
    152 }
    153
    154 /* Can be uninlined because referenced by paravirt */
    155 static inline int notrace

    Link: http://lkml.kernel.org/r/1521444205-2259-1-git-send-email-changbin.du@intel.com
    Signed-off-by: Changbin Du
    Cc: Thomas Gleixner
    Cc: Philippe Ombredanne
    Cc: NeilBrown
    Cc: Richard Weinberger
    Cc: Kate Stewart
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Changbin Du
     

15 Dec, 2017

1 commit

  • faddr2line hit var unbound error when CROSS_COMPILE isn't set since
    nounset option is set in bash script.

    Link: http://lkml.kernel.org/r/20171206013022.GA83929@sofia
    Fixes: 95a879825419 ("scripts/faddr2line: extend usage on generic arch")
    Signed-off-by: Liu Changcheng
    Reported-by: Richard Weinberger
    Reviewed-by: Richard Weinberger
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Philippe Ombredanne
    Cc: NeilBrown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Liu, Changcheng
     

30 Nov, 2017

1 commit

  • When cross-compiling, fadd2line should use the binary tool used for the
    target system, rather than that of the host.

    Link: http://lkml.kernel.org/r/20171121092911.GA150711@sofia
    Signed-off-by: Liu Changcheng
    Cc: Kate Stewart
    Cc: NeilBrown
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Liu, Changcheng
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

13 Oct, 2017

1 commit

  • If faddr2line is given a function name which is the last one listed by
    "nm -n", it will fail because it never finds the next symbol.

    So teach the awk script to catch that possibility, and use 'size' to
    provide the end point of the last function.

    Signed-off-by: NeilBrown
    Signed-off-by: Linus Torvalds

    NeilBrown
     

26 Oct, 2016

1 commit

  • I'm not sure how we missed this problem before. When I take a function
    address and size from an oops and give it to faddr2line, it usually
    complains about a size mismatch:

    $ scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60
    skipping write_sysrq_trigger address at 0xffffffff815731a1 due to size mismatch (0x60 != 83)
    no match for write_sysrq_trigger+0x51/0x60

    The problem is caused by differences in how kallsyms and faddr2line
    determine a function's size.

    kallsyms calculates a function's size by parsing the output of 'nm -n'
    and subtracting the next function's address from the current function's
    address. This means that nop instructions after the end of the function
    are included in the size.

    In contrast, faddr2line reads the size from the symbol table, which does
    *not* include the ending nops in the function's size.

    Change faddr2line to calculate the size from the output of 'nm -n' to be
    consistent with kallsyms and oops outputs.

    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/bd313ed7c4003f6b1fda63e825325c44a9d837de.1477405374.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf
     

20 Sep, 2016

2 commits

  • Due to our compiler include directives, the build pathnames for header
    files often end up being of the form "$srcdir/./include/linux/xyz.h",
    which ends up having that extra "." path component after the build base
    in it.

    Teach faddr2line to skip that too, to make code generated in inline
    functions in header files match the filename for the regular C files.

    Rabin Vincent pointed out that I can't make a stricter regexp match by
    using the " at " prefix for the pathname, because that ends up being
    locale-dependent. But this does require that the path match be preceded
    by a space, to make it a bit more strict (that matters mainly if we
    didn't find any base_dir at all, and we only end up with the "./" part
    of the match)

    Acked-by: Josh Poimboeuf
    Cc: Rabin Vincent
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • addr2line doesn't work with KASLR addresses. Add a basic addr2line
    wrapper script which takes the 'func+offset/size' format as input.

    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Linus Torvalds

    Josh Poimboeuf