#
23835308 |
|
25-Jul-2023 |
James Clark <james.clark@arm.com> |
scripts/kallsyms: Fix build failure by setting errno before calling getline() getline() returns -1 at EOF as well as on error. It also doesn't set errno to 0 on success, so initialize it to 0 before using errno to check for an error condition. See the paragraph here [1]: For some system calls and library functions (e.g., getpriority(2)), -1 is a valid return on success. In such cases, a successful return can be distinguished from an error return by setting errno to zero before the call, and then, if the call returns a status that indicates that an error may have occurred, checking to see if errno has a nonzero value. Bear has a bug [2] that launches processes with errno set and causes the following build failure: $ bear -- make LLVM=1 ... LD .tmp_vmlinux.kallsyms1 NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S read_symbol: Invalid argument [1]: https://linux.die.net/man/3/errno [2]: https://github.com/rizsotto/Bear/issues/469 Fixes: 1c975da56a6f ("scripts/kallsyms: remove KSYM_NAME_LEN_BUFFER") Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: James Clark <james.clark@arm.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
8cc32a9b |
|
28-Jun-2023 |
Yonghong Song <yhs@fb.com> |
kallsyms: strip LTO-only suffixes from promoted global functions Commit 6eb4bd92c1ce ("kallsyms: strip LTO suffixes from static functions") stripped all function/variable suffixes started with '.' regardless of whether those suffixes are generated at LTO mode or not. In fact, as far as I know, in LTO mode, when a static function/variable is promoted to the global scope, '.llvm.<...>' suffix is added. The existing mechanism breaks live patch for a LTO kernel even if no <symbol>.llvm.<...> symbols are involved. For example, for the following kernel symbols: $ grep bpf_verifier_vlog /proc/kallsyms ffffffff81549f60 t bpf_verifier_vlog ffffffff8268b430 d bpf_verifier_vlog._entry ffffffff8282a958 d bpf_verifier_vlog._entry_ptr ffffffff82e12a1f d bpf_verifier_vlog.__already_done 'bpf_verifier_vlog' is a static function. '_entry', '_entry_ptr' and '__already_done' are static variables used inside 'bpf_verifier_vlog', so llvm promotes them to file-level static with prefix 'bpf_verifier_vlog.'. Note that the func-level to file-level static function promotion also happens without LTO. Given a symbol name 'bpf_verifier_vlog', with LTO kernel, current mechanism will return 4 symbols to live patch subsystem which current live patching subsystem cannot handle it. With non-LTO kernel, only one symbol is returned. In [1], we have a lengthy discussion, the suggestion is to separate two cases: (1). new symbols with suffix which are generated regardless of whether LTO is enabled or not, and (2). new symbols with suffix generated only when LTO is enabled. The cleanup_symbol_name() should only remove suffixes for case (2). Case (1) should not be changed so it can work uniformly with or without LTO. This patch removed LTO-only suffix '.llvm.<...>' so live patching and tracing should work the same way for non-LTO kernel. The cleanup_symbol_name() in scripts/kallsyms.c is also changed to have the same filtering pattern so both kernel and kallsyms tool have the same expectation on the order of symbols. [1] https://lore.kernel.org/live-patching/20230615170048.2382735-1-song@kernel.org/T/#u Fixes: 6eb4bd92c1ce ("kallsyms: strip LTO suffixes from static functions") Reported-by: Song Liu <song@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20230628181926.4102448-1-yhs@fb.com Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
1c975da5 |
|
05-Jun-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: remove KSYM_NAME_LEN_BUFFER You do not need to decide the buffer size statically. Use getline() to grow the line buffer as needed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
#
92e74fb6 |
|
05-Jun-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: constify long_options getopt_long() does not modify this. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
#
79549da6 |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: update the usage in the comment block Commit 010a0aad39fc ("kallsyms: Correctly sequence symbols when CONFIG_LTO_CLANG=y") added --lto-clang, and updated the usage() function, but not the comment. Update it in the same way. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
|
#
dd1553b8 |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: decrease expand_symbol() / cleanup_symbol_name() calls Currently, expand_symbol() is called many times to get the uncompressed symbol names for sorting, and also for adding comments. With the output order shuffled in the previous commit, the symbol data are now written in the following order: (1) kallsyms_num_syms (2) kallsyms_names <-- need compressed names (3) kallsyms_markers (4) kallsyms_token_table (5) kallsyms_token_index (6) kallsyms_addressed / kallsyms_offsets <-- need uncompressed names (for commenting) (7) kallsyms_relative_base (8) kallsyms_seq_of_names <-- need uncompressed names (for sorting) The compressed names are only needed by (2). Call expand_symbol() between (2) and (3) to restore the original symbol names. This requires just one expand_symbol() call for each symbol. Call cleanup_symbol_name() between (7) and (8) instead of during sorting. It is allowed to overwrite the ->sym field because (8) just outputs the index instead of the name of each symbol. Again, this requires just one cleanup_symbol_name() call for each symbol. This refactoring makes it ~30% faster. [Before] $ time scripts/kallsyms --all-symbols --absolute-percpu --base-relative \ .tmp_vmlinux.kallsyms2.syms >/dev/null real 0m1.027s user 0m1.010s sys 0m0.016s [After] $ time scripts/kallsyms --all-symbols --absolute-percpu --base-relative \ .tmp_vmlinux.kallsyms2.syms >/dev/null real 0m0.717s user 0m0.717s sys 0m0.000s Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
404bad70 |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: change the output order Currently, this tool outputs symbol data in the following order. (1) kallsyms_addressed / kallsyms_offsets (2) kallsyms_relative_base (3) kallsyms_num_syms (4) kallsyms_names (5) kallsyms_markers (6) kallsyms_seq_of_names (7) kallsyms_token_table (8) kallsyms_token_index This commit changes the order as follows: (1) kallsyms_num_syms (2) kallsyms_names (3) kallsyms_markers (4) kallsyms_token_table (5) kallsyms_token_index (6) kallsyms_addressed / kallsyms_offsets (7) kallsyms_relative_base (8) kallsyms_seq_of_names The motivation is to decrease the number of function calls to expand_symbol() and cleanup_symbol_name(). The compressed names are only required for writing 'kallsyms_names'. If you do this first, we can restore the original symbol names. You do not need to repeat the same operation over again. The actual refactoring will happen in the next commit. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
320e7c9d |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: move compiler-generated symbol patterns to mksysmap scripts/kallsyms.c maintains compiler-generated symbols, but we end up with something similar in scripts/mksysmap to avoid the "Inconsistent kallsyms data" error. For example, commit c17a2538704f ("mksysmap: Fix the mismatch of 'L0' symbols in System.map"). They were separately maintained prior to commit 94ff2f63d6a3 ("kbuild: reuse mksysmap output for kallsyms"). Now that scripts/kallsyms.c parses the output of scripts/mksysmap, it makes more sense to collect all the ignored patterns to mksysmap. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
|
#
ca09bf48 |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: exclude symbols generated by itself dynamically Drop the symbols generated by scripts/kallsyms itself automatically instead of maintaining the symbol list manually. Pass the kallsyms object from the previous kallsyms step (if it exists) as the third parameter of scripts/mksysmap, which will weed out the generated symbols from the input to the next kallsyms step. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
a7b00a18 |
|
08-Mar-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: remove redundant code for omitting U and N The symbol types 'U' and 'N' are already filtered out by the following line in scripts/mksysmap: -e ' [aNUw] ' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
|
#
bea5b745 |
|
06-Mar-2023 |
Arnd Bergmann <arnd@arndb.de> |
kallsyms: expand symbol name into comment for debugging The assembler output of kallsyms.c is not meant for people to understand, and is generally not helpful when debugging "Inconsistent kallsyms data" warnings. I have previously struggled with these, but found it helpful to list which symbols changed between the first and second pass in the .tmp_vmlinux.kallsyms*.S files. As this file is preprocessed, it's possible to add a C-style multiline comment with the full type/name tuple. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
ced0f245 |
|
06-Mar-2023 |
Arnd Bergmann <arnd@arndb.de> |
kallsyms: add kallsyms_seqs_of_names to list of special symbols My randconfig build setup ran into another kallsyms warning: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround After adding some debugging code to kallsyms.c, I saw that the recently added kallsyms_seqs_of_names symbol can sometimes cause the second stage table to be slightly longer than the first stage, which makes the build inconsistent. Add it to the exception table that contains all other kallsyms-generated symbols. Fixes: 60443c88f3a8 ("kallsyms: Improve the performance of kallsyms_lookup_name()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
adc40221 |
|
18-Nov-2022 |
Yuma Ueda <cyan@0x00a1e9.dev> |
scripts/kallsyms.c Make the comment up-to-date with current implementation The comment in scripts/kallsyms.c describing the usage of scripts/kallsyms does not reflect the latest implementation. Fix the comment to be equivalent to what the usage() function prints. Signed-off-by: Yuma Ueda <cyan@0x00a1e9.dev> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20221118133631.4554-1-cyan@0x00a1e9.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
19bd8981 |
|
02-Nov-2022 |
Zhen Lei <thunder.leizhen@huawei.com> |
kallsyms: Reduce the memory occupied by kallsyms_seqs_of_names[] kallsyms_seqs_of_names[] records the symbol index sorted by address, the maximum value in kallsyms_seqs_of_names[] is the number of symbols. And 2^24 = 16777216, which means that three bytes are enough to store the index. This can help us save (1 * kallsyms_num_syms) bytes of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
|
#
010a0aad |
|
02-Nov-2022 |
Zhen Lei <thunder.leizhen@huawei.com> |
kallsyms: Correctly sequence symbols when CONFIG_LTO_CLANG=y LLVM appends various suffixes for local functions and variables, suffixes observed: - foo.llvm.[0-9a-f]+ - foo.[0-9a-f]+ Therefore, when CONFIG_LTO_CLANG=y, kallsyms_lookup_name() needs to truncate the suffix of the symbol name before comparing the local function or variable name. Old implementation code: - if (strcmp(namebuf, name) == 0) - return kallsyms_sym_address(i); - if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0) - return kallsyms_sym_address(i); The preceding process is traversed by address from low to high. That is, for those with the same name after the suffix is removed, the one with the smallest address is returned first. Therefore, when sorting in the tool, if the raw names are the same, they should be sorted by address in ascending order. ASCII[.] = 2e ASCII[0-9] = 30,39 ASCII[A-Z] = 41,5a ASCII[_] = 5f ASCII[a-z] = 61,7a According to the preceding ASCII code values, the following sorting result is strictly followed. --------------------------------- | main-key | sub-key | |---------------------------------| | | addr_lowest | | <name> | ... | | <name>.<suffix> | ... | | | addr_highest | |---------------------------------| | <name>?<others> | | //? is [_A-Za-z0-9] --------------------------------- Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
|
#
60443c88 |
|
02-Nov-2022 |
Zhen Lei <thunder.leizhen@huawei.com> |
kallsyms: Improve the performance of kallsyms_lookup_name() Currently, to search for a symbol, we need to expand the symbols in 'kallsyms_names' one by one, and then use the expanded string for comparison. It's O(n). If we sort names in ascending order like addresses, we can also use binary search. It's O(log(n)). In order not to change the implementation of "/proc/kallsyms", the table kallsyms_names[] is still stored in a one-to-one correspondence with the address in ascending order. Add array kallsyms_seqs_of_names[], it's indexed by the sequence number of the sorted names, and the corresponding content is the sequence number of the sorted addresses. For example: Assume that the index of NameX in array kallsyms_seqs_of_names[] is 'i', the content of kallsyms_seqs_of_names[i] is 'k', then the corresponding address of NameX is kallsyms_addresses[k]. The offset in kallsyms_names[] is get_symbol_offset(k). Note that the memory usage will increase by (4 * kallsyms_num_syms) bytes, the next two patches will reduce (1 * kallsyms_num_syms) bytes and properly handle the case CONFIG_LTO_CLANG=y. Performance test results: (x86) Before: min=234, max=10364402, avg=5206926 min=267, max=11168517, avg=5207587 After: min=1016, max=90894, avg=7272 min=1014, max=93470, avg=7293 The average lookup performance of kallsyms_lookup_name() improved 715x. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
|
#
fcdf7197 |
|
02-Nov-2022 |
Zhen Lei <thunder.leizhen@huawei.com> |
scripts/kallsyms: rename build_initial_tok_table() Except for the function build_initial_tok_table(), no token abbreviation is used elsewhere. $ cat scripts/kallsyms.c | grep tok | wc -l 33 $ cat scripts/kallsyms.c | grep token | wc -l 31 Here, it would be clearer to use the full name. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
|
#
aa221f2e |
|
26-Sep-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kallsyms: take the input file instead of reading stdin This gets rid of the pipe operator connected with 'cat'. Also use getopt_long() to parse the command line. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
a2833d1b |
|
26-Sep-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kallsyms: drop duplicated ignore patterns from kallsyms.c Now that kallsyms.c parses the output from mksysmap, some symbols have already been dropped. Move comments to scripts/mksysmap. Also, make the grep command readable. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
b8a94bfb |
|
04-Apr-2021 |
Miguel Ojeda <ojeda@kernel.org> |
kallsyms: increase maximum kernel symbol length to 512 Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. For instance, the following code: pub mod my_module { pub struct MyType; pub struct MyGenericType<T>(T); pub trait MyTrait { fn my_method() -> u32; } impl MyTrait for MyGenericType<MyType> { fn my_method() -> u32 { 42 } } } generates a symbol of length 96 when using the upcoming v0 mangling scheme: _RNvXNtCshGpAVYOtgW1_7example9my_moduleINtB2_13MyGenericTypeNtB2_6MyTypeENtB2_7MyTrait9my_method At the moment, Rust symbols may reach up to 300 in length. Setting 512 as the maximum seems like a reasonable choice to keep some headroom. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
#
73bbb944 |
|
04-Apr-2021 |
Miguel Ojeda <ojeda@kernel.org> |
kallsyms: support "big" kernel symbols Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. Increasing to 255 is not enough in some cases, therefore introduce longer lengths to the symbol table. In order to avoid increasing all lengths to 2 bytes (since most of them are small, including many Rust ones), use ULEB128 to keep smaller symbols in 1 byte, with the rest in 2 bytes. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Co-developed-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
#
6e8c5bbd |
|
27-Jul-2022 |
Miguel Ojeda <ojeda@kernel.org> |
kallsyms: add static relationship between `KSYM_NAME_LEN{,_BUFFER}` This adds a static assert to ensure `KSYM_NAME_LEN_BUFFER` gets updated when `KSYM_NAME_LEN` changes. The relationship used is one that keeps the new size (512+1) close to the original buffer size (500). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
#
b471927e |
|
27-Jul-2022 |
Boqun Feng <boqun.feng@gmail.com> |
kallsyms: avoid hardcoding buffer size This introduces `KSYM_NAME_LEN_BUFFER` in place of the previously hardcoded size of the input buffer. It will also make it easier to update the size in a single place in a later patch. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Co-developed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
#
b66c874f |
|
27-Jul-2022 |
Boqun Feng <boqun.feng@gmail.com> |
kallsyms: use `ARRAY_SIZE` instead of hardcoded size This removes one place where the `500` constant is hardcoded. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Geert Stappers <stappers@stappers.nl> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Co-developed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
#
d0f9562e |
|
08-Sep-2022 |
Sami Tolvanen <samitolvanen@google.com> |
scripts/kallsyms: Ignore __kcfi_typeid_ The compiler generates __kcfi_typeid_ symbols for annotating assembly functions with type information. These are constants that can be referenced in assembly code and are resolved by the linker. Ignore them in kallsyms. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220908215504.3686827-3-samitolvanen@google.com
|
#
8d3a7507 |
|
22-May-2022 |
Yuntao Wang <ytcoode@gmail.com> |
scripts/kallsyms: update usage message of the kallsyms program The kallsyms program supports --absolute-percpu option but does not display it in the usage message, fix it. Signed-off-by: Yuntao Wang <ytcoode@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
6ccf9cb5 |
|
20-Apr-2022 |
Kalesh Singh <kaleshsingh@google.com> |
KVM: arm64: Symbolize the nVHE HYP addresses Reintroduce the __kvm_nvhe_ symbols in kallsyms, ignoring the local symbols in this namespace. The local symbols are not informative and can cause aliasing issues when symbolizing the addresses. With the necessary symbols now in kallsyms we can symbolize nVHE addresses using the %p print format specifier: [ 98.916444][ T426] kvm [426]: nVHE hyp panic at: [<ffffffc0096156fc>] __kvm_nvhe_overflow_stack+0x8/0x34! Signed-off-by: Kalesh Singh <kaleshsingh@google.com> Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220420214317.3303360-7-kaleshsingh@google.com
|
#
d4c85864 |
|
31-Jan-2022 |
Changbin Du <changbin.du@intel.com> |
kallsyms: ignore all local labels prefixed by '.L' The llvm compiler can generate lots of local labels ('.LBB', '.Ltmpxxx', '.L__unnamed_xx', etc.). These symbols usually are useless for debugging. And they might overlap with handwritten symbols. Before this change, a dumpstack shows a local symbol for epc: [ 0.040341][ T0] Hardware name: riscv-virtio,qemu (DT) [ 0.040376][ T0] epc : .LBB6_14+0x22/0x6a [ 0.040452][ T0] ra : restore_all+0x12/0x6e The simple solution is that we can ignore all local labels prefixed by '.L'. For handwritten symbols which need to be preserved should drop the '.L' prefix. After this change, the C defined symbol is shown so we can locate the problematical code immediately: [ 0.035795][ T0] Hardware name: riscv-virtio,qemu (DT) [ 0.036332][ T0] epc : trace_hardirqs_on+0x54/0x13c [ 0.036567][ T0] ra : restore_all+0x12/0x6e Signed-off-by: Changbin Du <changbin.du@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
efe6e306 |
|
04-Feb-2021 |
Arnd Bergmann <arnd@arndb.de> |
kallsyms: fix nonconverging kallsyms table with lld ARM randconfig builds with lld sometimes show a build failure from kallsyms: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround The problem is the veneers/thunks getting added by the linker extend the symbol table, which in turn leads to more veneers being needed, so it may take a few extra iterations to converge. This bug has been fixed multiple times before, but comes back every time a new symbol name is used. lld uses a different set of identifiers from ld.bfd, so the additional ones need to be added as well. I looked through the sources and found that arm64 and mips define similar prefixes, so I'm adding those as well, aside from the ones I observed. I'm not sure about powerpc64, which seems to already be handled through a section match, but if it comes back, the "__long_branch_" and "__plt_" prefixes would have to get added as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
516d980f |
|
22-Sep-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: skip ppc compiler stub *.long_branch.* / *.plt_branch.* PowerPC allmodconfig often fails to build as follows: LD .tmp_vmlinux.kallsyms1 KSYM .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 KSYM .tmp_vmlinux.kallsyms2.o LD .tmp_vmlinux.kallsyms3 KSYM .tmp_vmlinux.kallsyms3.o LD vmlinux SORTTAB vmlinux SYSMAP System.map Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround make[2]: *** [../Makefile:1162: vmlinux] Error 1 Setting KALLSYMS_EXTRA_PASS=1 does not help. This is caused by the compiler inserting stubs such as *.long_branch.* and *.plt_branch.* $ powerpc-linux-nm -n .tmp_vmlinux.kallsyms2 [ snip ] c00000000210c010 t 00000075.plt_branch.da9:19 c00000000210c020 t 00000075.plt_branch.1677:5 c00000000210c030 t 00000075.long_branch.memmove c00000000210c034 t 00000075.plt_branch.9e0:5 c00000000210c044 t 00000075.plt_branch.free_initrd_mem ... Actually, the problem mentioned in scripts/link-vmlinux.sh comments; "In theory it's possible this results in even more stubs, but unlikely" is happening here, and ends up with another kallsyms step required. scripts/kallsyms.c already ignores various compiler stubs. Let's do similar to make kallsysms for PowerPC always succeed in 2 steps. Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Guenter Roeck <linux@roeck-us.net>
|
#
76217129 |
|
25-Jun-2020 |
David Brazdil <dbrazdil@google.com> |
KVM: arm64: Add build rules for separate VHE/nVHE object files Add new folders arch/arm64/kvm/hyp/{vhe,nvhe} and Makefiles for building code that runs in EL2 under VHE/nVHE KVM, repsectivelly. Add an include folder for hyp-specific header files which will include code common to VHE/nVHE. Build nVHE code with -D__KVM_NVHE_HYPERVISOR__, VHE code with -D__KVM_VHE_HYPERVISOR__. Under nVHE compile each source file into a `.hyp.tmp.o` object first, then prefix all its symbols with "__kvm_nvhe_" using `objcopy` and produce a `.hyp.o`. Suffixes were chosen so that it would be possible for VHE and nVHE to share some source files, but compiled with different CFLAGS. The nVHE ELF symbol prefix is added to kallsyms.c as ignored. EL2-only symbols will never appear in EL1 stack traces. Due to symbol prefixing, add a section in image-vars.h for aliases of symbols that are defined in nVHE EL2 and accessed by kernel in EL1 or vice versa. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200625131420.71444-4-dbrazdil@google.com
|
#
9d82973e |
|
04-May-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
gcc-10 warnings: fix low-hanging fruit Due to a bug-report that was compiler-dependent, I updated one of my machines to gcc-10. That shows a lot of new warnings. Happily they seem to be mostly the valid kind, but it's going to cause a round of churn for getting rid of them.. This is the really low-hanging fruit of removing a couple of zero-sized arrays in some core code. We have had a round of these patches before, and we'll have many more coming, and there is nothing special about these except that they were particularly trivial, and triggered more warnings than most. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7883a143 |
|
11-Mar-2020 |
Mikhail Petrov <Mikhail.Petrov@mir.dev> |
scripts/kallsyms: fix wrong kallsyms_relative_base There is the code in the read_symbol function in 'scripts/kallsyms.c': if (is_ignored_symbol(name, type)) return NULL; /* Ignore most absolute/undefined (?) symbols. */ if (strcmp(name, "_text") == 0) _text = addr; But the is_ignored_symbol function returns true for name="_text" and type='A'. So the next condition is not executed and the _text variable is always zero. It makes the wrong kallsyms_relative_base symbol as a result of the code (CONFIG_KALLSYMS_BASE_RELATIVE is defined): if (base_relative) { output_label("kallsyms_relative_base"); output_address(relative_base); printf("\n"); } Because the output_address function uses the _text variable. So the kallsyms_lookup function and all related functions in the kernel do not work properly. For example, the stack trace in oops: Call Trace: [aa095e58] [809feab8] kobj_ns_ops_tbl+0x7ff09ac8/0x7ff1c1c4 (unreliable) [aa095e98] [80002b64] kobj_ns_ops_tbl+0x7f50db74/0x80000010 [aa095ef8] [809c3d24] kobj_ns_ops_tbl+0x7feced34/0x7ff1c1c4 [aa095f28] [80002ed0] kobj_ns_ops_tbl+0x7f50dee0/0x80000010 [aa095f38] [8000f238] kobj_ns_ops_tbl+0x7f51a248/0x80000010 The right stack trace: Call Trace: [aa095e58] [809feab8] module_vdu_video_init+0x2fc/0x3bc (unreliable) [aa095e98] [80002b64] do_one_initcall+0x40/0x1f0 [aa095ef8] [809c3d24] kernel_init_freeable+0x164/0x1d8 [aa095f28] [80002ed0] kernel_init+0x14/0x124 [aa095f38] [8000f238] ret_from_kernel_thread+0x14/0x1c [masahiroy@kernel.org: This issue happens on binutils <= 2.22 The following commit fixed it: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d2667025dd30611514810c28bee9709e4623012a The symbol type of _text is 'T' on binutils >= 2.23 The minimal supported binutils version for the kernel build is 2.21 ] Signed-off-by: Mikhail Petrov <Mikhail.Petrov@mir.dev> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
9d1b3895 |
|
10-Feb-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: fix memory corruption caused by write over-run memcpy() writes one more byte than allocated. Fixes: 8d60526999aa ("scripts/kallsyms: change table to store (strcut sym_entry *)") Reported-by: youling257 <youling257@gmail.com> Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Pavel Machek <pavel@ucw.cz>
|
#
8d605269 |
|
01-Feb-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: change table to store (strcut sym_entry *) The symbol table is extended every 10000 addition by using realloc(), where data copy might occur to the new buffer. To decrease the amount of possible data copy, let's change the table to store the pointer. The symbol type + symbol name part is appended at the end of (struct sym_entry), and allocated together with the struct body. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
be9f6133 |
|
01-Feb-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: rename local variables in read_symbol() I will use 'sym' for the point to struce sym_entry in the next commit. Rename 'sym', 'stype' to 'name', 'type', which are more intuitive. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
fd2ab2f6 |
|
08-Dec-2019 |
Masahiro Yamada <masahiroy@kernel.org> |
scripts/kallsyms: fix offset overflow of kallsyms_relative_base Since commit 5e5c4fa78745 ("scripts/kallsyms: shrink table before sorting it"), kallsyms_relative_base can be larger than _text, which causes overflow when building the 32-bit kernel. https://lkml.org/lkml/2019/12/7/156 This is because _text is, unless --all-symbols is specified, now trimmed from the symbol table before record_relative_base() is called. Handle the offset signedness also for kallsyms_relative_base. Introduce a new helper, output_address(), to reduce the code duplication. Fixes: 5e5c4fa78745 ("scripts/kallsyms: shrink table before sorting it") Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
831362fc |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: remove redundant initializers These are set to zero without the explicit initializers. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
d44270fc |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: put check_symbol_range() calls close together Put the relevant code close together. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
b6233d0d |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: make check_symbol_range() void function There is no more reason to check the return value of check_symbol_range(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
887df76d |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: move ignored symbol types to is_ignored_symbol() Collect the ignored patterns to is_ignored_symbol(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
97261e1e |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: move more patterns to the ignored_prefixes array Refactoring for shortening the code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
a41333e0 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: skip ignored symbols very early Unless the address range matters, symbols can be ignored earlier, which avoids unneeded memory allocation. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
4bfe2b78 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: add const qualifiers where possible Add 'const' where a function does not write to the pointer dereferenes. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
2558c138 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: make find_token() return (unsigned char *) The callers of this function expect (unsigned char *). I do not see a good reason to make this function return (void *). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
aa915245 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: replace prefix_underscores_count() with strspn() You can do equivalent things with strspn(). I do not see noticeable performance difference. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
29e55ad3 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: add sym_name() to mitigate cast ugliness sym_entry::sym is (unsigned char *) instead of (char *) because kallsyms exploits the MSB for compression, and the characters are used as the index of token_profit array. However, it requires casting (unsigned char *) to (char *) in some places since standard library functions such as strcmp(), strlen() expect (char *). Introduce a new helper, sym_name(), which advances the given pointer by 1 and casts it to (char *). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
c5e5002f |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: remove unneeded length check for prefix matching l <= strlen(sym_name) is unnecessary for prefix matching. strncmp() will do. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
e0109042 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: remove redundant is_arm_mapping_symbol() Since commit 6f00df24ee39 ("[PATCH] Strip local symbols from kallsyms"), all symbols starting '$' are ignored. is_arm_mapping_symbol() particularly ignores $a, $t, etc. but it is redundant. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
f34ea029 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: set relative_base more effectively Currently, record_relative_base() iterates over the entire table to find the minimum address, but it is not efficient because we sort the table anyway. After sort_symbol(), the table is sorted by address. (kallsyms parses the 'nm -n' output, so the data is already sorted by address, but this commit does not rely on it.) Move record_relative_base() after sort_symbols(), and take the first non-absolute symbol value. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
5e5c4fa7 |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: shrink table before sorting it Currently, build_initial_tok_table() trims unused symbols, but it is called after sort_symbols(). It is not efficient to sort the huge table that contains unused entries. Shrink the table before sorting it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
21915eca |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: fix definitely-lost memory leak build_initial_tok_table() overwrites unused sym_entry to shrink the table size. Before the entry is overwritten, table[i].sym must be freed since it is malloc'ed data. This fixes the 'definitely lost' report from valgrind. I ran valgrind against x86_64_defconfig of v5.4-rc8 kernel, and here is the summary: [Before the fix] LEAK SUMMARY: definitely lost: 53,184 bytes in 2,874 blocks [After the fix] LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
1ef26b7c |
|
23-Nov-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/kallsyms: remove unneeded #ifndef ARRAY_SIZE This is not defined in the standard headers. #ifndef is unneeded. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
33177f01 |
|
28-Jun-2019 |
Vasily Gorbik <gor@linux.ibm.com> |
kallsyms: exclude kasan local symbols on s390 gcc asan instrumentation emits the following sequence to store frame pc when the kernel is built with CONFIG_RELOCATABLE: debug/vsprintf.s: .section .data.rel.ro.local,"aw" .align 8 .LC3: .quad .LASANPC4826@GOTOFF .text .align 8 .type number, @function number: .LASANPC4826: and in case reloc is issued for LASANPC label it also gets into .symtab with the same address as actual function symbol: $ nm -n vmlinux | grep 0000000001397150 0000000001397150 t .LASANPC4826 0000000001397150 t number In the end kernel backtraces are almost unreadable: [ 143.748476] Call Trace: [ 143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190) [ 143.748492] [<000000002eca1a58>] .LASANPC2612+0x110/0x160 [ 143.748502] [<000000002de9d830>] print_address_description+0x80/0x3b0 [ 143.748511] [<000000002de9dd64>] __kasan_report+0x15c/0x1c8 [ 143.748521] [<000000002ecb56d4>] strrchr+0x34/0x60 [ 143.748534] [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan] [ 143.748547] [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan] [ 143.748555] [<000000002da2117c>] .LASANPC4069+0x354/0x748 [ 143.748563] [<000000002dbfbb16>] do_init_module+0x136/0x3b0 [ 143.748571] [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0 [ 143.748580] [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8 [ 143.748587] [<000000002ecdf2ec>] system_call+0xd8/0x2d8 Since LASANPC labels are not even unique and get into .symtab only due to relocs filter them out in kallsyms. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
500193ec |
|
03-Feb-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kallsyms: include <asm/bitsperlong.h> instead of <asm/types.h> <asm/bitsperlong.h> is enough to include the definition of BITS_PER_LONG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
52a849ed |
|
03-Feb-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kallsyms: remove unneeded memset() calls Global variables in the .bss section are zeroed out before the program starts to run. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
f43e9daa |
|
03-Feb-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kallsyms: add static qualifiers where missing Fix the following sparse warnings: scripts/kallsyms.c:65:5: warning: symbol 'token_profit' was not declared. Should it be static? scripts/kallsyms.c:68:15: warning: symbol 'best_table' was not declared. Should it be static? scripts/kallsyms.c:69:15: warning: symbol 'best_table_len' was not declared. Should it be static? Also, remove 'inline' from is_arm_mapping_symbol(). The compiler will inline it anyway when it is appropriate to do so. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
6db2983c |
|
17-Jan-2019 |
Eugene Loh <eugene.loh@oracle.com> |
kallsyms: Handle too long symbols in kallsyms.c When checking for symbols with excessively long names, account for null terminating character. Fixes: f3462aa952cf ("Kbuild: Handle longer symbols in kallsyms.c") Signed-off-by: Eugene Loh <eugene.loh@oracle.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
72d3ebb9 |
|
30-Dec-2018 |
Mathias Krause <minipli@googlemail.com> |
kallsyms: lower alignment on ARM As mentioned in the info pages of gas, the '.align' pseudo op's interpretation of the alignment value is architecture specific. It might either be a byte value or taken to the power of two. On ARM it's actually the latter which leads to unnecessary large alignments of 16 bytes for 32 bit builds or 256 bytes for 64 bit builds. Fix this by switching to '.balign' instead which is consistent across all architectures. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
36f546a1 |
|
03-Sep-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kallsyms: remove left-over Blackfin code These symbols were added by commit 028f042613c3 ("kallsyms: support kernel symbols in Blackfin on-chip memory") for Blackfin. The Blackfin support was removed by commit 4ba66a976072 ("arch: remove blackfin port"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
80ffbaa5 |
|
03-Sep-2018 |
Jan Beulich <JBeulich@suse.com> |
kallsyms: reduce size a little on 64-bit Both kallsyms_num_syms and kallsyms_markers[] don't really need to use unsigned long as their (base) types; unsigned int fully suffices. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
ac5db1fc |
|
23-May-2018 |
nixiaoming <nixiaoming@huawei.com> |
scripts: Fixed printf format mismatch scripts/kallsyms.c: function write_src: "printf", the #1 format specifier "d" need arg type "int", but the according arg "table_cnt" has type "unsigned int" scripts/recordmcount.c: function do_file: "fprintf", the #1 format specifier "d" need arg type "int", but the according arg "(*w2)(ehdr->e_machine)" has type "unsigned int" scripts/recordmcount.h: function find_secsym_ndx: "fprintf", the #1 format specifier "d" need arg type "int", but the according arg "txtndx" has type "unsigned int" Signed-off-by: nixiaoming <nixiaoming@huawei.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
534c9f2e |
|
09-May-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kallsyms: remove symbol prefix support CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX was selected by BLACKFIN, METAG. They were removed by commit 4ba66a976072 ("arch: remove blackfin port"), commit bb6fb6dfcc17 ("metag: Remove arch/metag/"), respectively. No more architecture enables CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX, hence the --symbol-prefix option is unnecessary. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
|
#
1212f7a1 |
|
01-Mar-2018 |
Ard Biesheuvel <ardb@kernel.org> |
scripts/kallsyms: filter arm64's __efistub_ symbols On arm64, the EFI stub and the kernel proper are essentially the same binary, although the EFI stub executes at a different virtual address as the kernel. For this reason, the EFI stub is restricted in the symbols it can link to, which is ensured by prefixing all EFI stub symbols with __efistub_ (and emitting __efistub_ prefixed aliases for routines that may be shared between the core kernel and the stub) These symbols are leaking into kallsyms, polluting the namespace, so let's filter them explicitly. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
cbf7a90e |
|
27-Feb-2018 |
Cao jin <caoj.fnst@cn.fujitsu.com> |
kbuild/kallsyms: trivial typo fix Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
51962a9d |
|
13-Oct-2017 |
Guenter Roeck <linux@roeck-us.net> |
scripts/kallsyms.c: ignore symbol type 'n' gcc on aarch64 may emit synbols of type 'n' if the kernel is built with '-frecord-gcc-switches'. In most cases, those symbols are reported with nm as 000000000000000e n $d and with objdump as 0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line 000000000000000e l .GCC.command.line 0000000000000000 $d Those symbols are detected in is_arm_mapping_symbol() and ignored. However, if "--prefix-symbols=<prefix>" is configured as well, the situation is different. For example, in efi/libstub, arm64 images are built with '--prefix-alloc-sections=.init --prefix-symbols=__efistub_'. In combination with '-frecord-gcc-switches', the symbols are now reported by nm as: 000000000000000e n __efistub_$d and by objdump as: 0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line 000000000000000e l .GCC.command.line 0000000000000000 __efistub_$d Those symbols are no longer ignored and included in the base address calculation. This results in a base address of 000000000000000e, which in turn causes kallsyms to abort with kallsyms failure: relative symbol value 0xffffff900800a000 out of range in relative mode The problem is seen in little endian arm64 builds with CONFIG_EFI enabled and with '-frecord-gcc-switches' set in KCFLAGS. Explicitly ignore symbols of type 'n' since those are clearly debug symbols. Link: http://lkml.kernel.org/r/1507136063-3139-1-git-send-email-linux@roeck-us.net Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
56067812 |
|
03-Feb-2017 |
Ard Biesheuvel <ardb@kernel.org> |
kbuild: modversions: add infrastructure for emitting relative CRCs This add the kbuild infrastructure that will allow architectures to emit vmlinux symbol CRCs as 32-bit offsets to another location in the kernel where the actual value is stored. This works around problems with CRCs being mistaken for relocatable symbols on kernels that self relocate at runtime (i.e., powerpc with CONFIG_RELOCATABLE=y) For the kbuild side of things, this comes down to the following: - introducing a Kconfig symbol MODULE_REL_CRCS - adding a -R switch to genksyms to instruct it to emit the CRC symbols as references into the .rodata section - making modpost distinguish such references from absolute CRC symbols by the section index (SHN_ABS) - making kallsyms disregard non-absolute symbols with a __crc_ prefix Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0f66784a |
|
28-Oct-2016 |
Ard Biesheuvel <ardb@kernel.org> |
scripts/kallsyms: remove last remnants of --page-offset option The implementation of the --page-offset kallsyms command line option has been removed, so remove it from the usage string as well. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.com>
|
#
2d958639 |
|
29-Mar-2016 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 8553/1: kallsyms: remove --page-offset command line option The --page-offset command line option was only used for ARM, to filter symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so remove the functionality altogether. Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
#
b9b74be1 |
|
01-Apr-2016 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 8555/1: kallsyms: ignore ARM mode switching veneers On ARM, the linker may emit veneers to deal with relative branch instructions that appear too far away from their targets. Since the second kallsyms pass results in an increase of the kernel size, it may result in additional veneers to be emitted, potentially affecting the output of kallsyms itself if these symbols are visible to it, and for that reason, symbols whose names end in '_veneer' are ignored explicitly. However, when building Thumb2 kernels, such veneers are named differently if they also incur a mode switch, and since they are not filtered by kallsyms, they may cause the build to fail. So filter symbols whose names end in '_from_arm' or '_from_thumb' as well. Tested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
#
2213e9a6 |
|
15-Mar-2016 |
Ard Biesheuvel <ardb@kernel.org> |
kallsyms: add support for relative offsets in kallsyms address table Similar to how relative extables are implemented, it is possible to emit the kallsyms table in such a way that it contains offsets relative to some anchor point in the kernel image rather than absolute addresses. On 64-bit architectures, it cuts the size of the kallsyms address table in half, since offsets between kernel symbols can typically be expressed in 32 bits. This saves several hundreds of kilobytes of permanent .rodata on average. In addition, the kallsyms address table is no longer subject to dynamic relocation when CONFIG_RELOCATABLE is in effect, so the relocation work done after decompression now doesn't have to do relocation updates for all these values. This saves up to 24 bytes (i.e., the size of a ELF64 RELA relocation table entry) per value, which easily adds up to a couple of megabytes of uncompressed __init data on ppc64 or arm64. Even if these relocation entries typically compress well, the combined size reduction of 2.8 MB uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init data) results in a ~500 KB space saving in the compressed image. Since it is useful for some architectures (like x86) to retain the ability to emit absolute values as well, this patch also adds support for capturing both absolute and relative values when KALLSYMS_ABSOLUTE_PERCPU is in effect, by emitting absolute per-cpu addresses as positive 32-bit values, and addresses relative to the lowest encountered relative symbol as negative values, which are subtracted from the runtime address of this base symbol to produce the actual address. Support for the above is enabled by default for all architectures except IA-64 and Tile-GX, whose symbols are too far apart to capture in this manner. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8c996940 |
|
15-Mar-2016 |
Ard Biesheuvel <ardb@kernel.org> |
kallsyms: don't overload absolute symbol type for percpu symbols Commit c6bda7c988a5 ("kallsyms: fix percpu vars on x86-64 with relocation") overloaded the 'A' (absolute) symbol type to signify that a symbol is not subject to dynamic relocation. However, the original A type does not imply that at all, and depending on the version of the toolchain, many A type symbols are emitted that are in fact relative to the kernel text, i.e., if the kernel is relocated at runtime, these symbols should be updated as well. For instance, on sparc32, the following symbols are emitted as absolute (kindly provided by Guenter Roeck): f035a420 A _etext f03d9000 A _sdata f03de8c4 A jiffies f03f8860 A _edata f03fc000 A __init_begin f041bdc8 A __init_text_end f0423000 A __bss_start f0423000 A __init_end f044457d A __bss_stop f044457d A _end On x86_64, similar behavior can be observed: ffffffff81a00000 A __end_rodata_hpage_align ffffffff81b19000 A __vvar_page ffffffff81d3d000 A _end Even if only a couple of them pass the symbol range check that results in them to be taken into account for the final kallsyms symbol table, it is obvious that 'A' does not mean the symbol does not need to be updated at relocation time, and overloading its meaning to signify that is perhaps not a good idea. So instead, add a new percpu_absolute member to struct sym_entry, and when --absolute-percpu is in effect, use it to record symbols whose addresses should be emitted as final values rather than values that still require relocation at runtime. That way, we can drop the check against the 'A' type. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michal Marek <mmarek@suse.cz> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
41b585b2 |
|
30-Mar-2015 |
Ard Biesheuvel <ardb@kernel.org> |
Kbuild: kallsyms: drop special handling of pre-3.0 GCC symbols Since we have required at least GCC v3.2 for some time now, we can drop the special handling of the 'gcc[0-9]_compiled.' label which is not emitted anymore since GCC v3.0. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
bd8b22d2 |
|
30-Mar-2015 |
Ard Biesheuvel <ardb@kernel.org> |
Kbuild: kallsyms: ignore veneers emitted by the ARM linker When linking large kernels on ARM, the linker will insert veneers (i.e., PLT like stubs) when function symbols are out of reach for the ordinary relative branch/branch-and-link instructions. However, due to the fact that the kallsyms region sits in .rodata, which is between .text and .init.text, additional veneers may be emitted in the second pass due to the fact that the size of the kallsyms region itself has pushed the .init.text section further apart, requiring even more veneers. So ignore the veneers when generating the symbol table. Veneers have no corresponding source code, and they will not turn up in backtraces anyway. This patch also lightly refactors the symbol_valid() function to use a local 'sym_name' rather than the obfuscated 'sym + 1' and 'sym + offset' Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
6c34f1f5 |
|
16-Sep-2014 |
Kyle McMartin <kyle@redhat.com> |
aarch64: filter $x from kallsyms Similar to ARM, AArch64 is generating $x and $d syms... which isn't terribly helpful when looking at %pF output and the like. Filter those out in kallsyms, modpost and when looking at module symbols. Seems simplest since none of these check EM_ARM anyway, to just add it to the strchr used, rather than trying to make things overly complicated. initcall_debug improves: dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs Signed-off-by: Kyle McMartin <kyle@redhat.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
bb66fc67 |
|
10-Jun-2014 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
kbuild: trivial - use tabs for code indent where possible Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
c6bda7c9 |
|
16-Mar-2014 |
Rusty Russell <rusty@rustcorp.com.au> |
kallsyms: fix percpu vars on x86-64 with relocation. x86-64 has a problem: per-cpu variables are actually represented by their absolute offsets within the per-cpu area, but the symbols are not emitted as absolute. Thus kallsyms naively creates them as offsets from _text, meaning their values change if the kernel is relocated (especially noticeable with CONFIG_RANDOMIZE_BASE): $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.nokaslr 0000000000000000 D __per_cpu_start 0000000000004000 D gdt_page 0000000000014280 D __per_cpu_end ffffffff810001c8 T _stext ffffffff81ee53c0 D __per_cpu_offset $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.kaslr1 000000001f200000 D __per_cpu_start 000000001f204000 D gdt_page 000000001f214280 D __per_cpu_end ffffffffa02001c8 T _stext ffffffffa10e53c0 D __per_cpu_offset Making them absolute symbols is the Right Thing, but requires fixes to the relocs tool. So for the moment, we add a --absolute-percpu option which makes them absolute from a kallsyms perspective: $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # no KASLR 0000000000000000 A __per_cpu_start 000000000000a000 A gdt_page 0000000000013040 A __per_cpu_end ffffffff802001c8 T _stext ffffffff8099b180 D __per_cpu_offset ffffffff809a3000 D __per_cpu_load $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # With KASLR 0000000000000000 A __per_cpu_start 000000000000a000 A gdt_page 0000000000013040 A __per_cpu_end ffffffff89c001c8 T _stext ffffffff8a39d180 D __per_cpu_offset ffffffff8a3a5000 D __per_cpu_load Based-on-the-original-screenplay-by: Andy Honig <ahonig@google.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Kees Cook <keescook@chromium.org>
|
#
78eb7159 |
|
16-Mar-2014 |
Kees Cook <keescook@chromium.org> |
kallsyms: generalize address range checking This refactors the address range checks to be generalized instead of specific to text range checks, in preparation for other range checks. Also extracts logic for "is the symbol absolute" into a function. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
#
2930ffc7 |
|
10-Mar-2014 |
Andrew Morton <akpm@linux-foundation.org> |
revert "kallsyms: fix absolute addresses for kASLR" Revert the recently applied 0f55159d091c ("kallsyms: fix absolute addresses for kASLR"). Kees said : This got NAKed, please don't apply -- this patch works for x86 and : ARM, but may cause problems for others: : : https://lkml.org/lkml/2014/2/24/718 It appears that Kees will be fixing all this up for 3.15. Cc: Andy Honig <ahonig@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0f55159d |
|
03-Mar-2014 |
Andy Honig <ahonig@google.com> |
kallsyms: fix absolute addresses for kASLR Currently symbols that are absolute addresses are incorrectly displayed in /proc/kallsyms if the kernel is loaded with kASLR. The problem was that the scripts/kallsyms.c file which generates the array of symbol names and addresses uses an relocatable value for all symbols, even absolute symbols. This patch fixes that. Several kallsyms output in different boot states for comparison: $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.nokaslr 0000000000000000 D __per_cpu_start 0000000000014280 D __per_cpu_end ffffffff810001c8 T _stext $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr1 000000001f200000 D __per_cpu_start 000000001f214280 D __per_cpu_end ffffffffa02001c8 T _stext $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr2 000000000d400000 D __per_cpu_start 000000000d414280 D __per_cpu_end ffffffff8e4001c8 T _stext $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr-fixed 0000000000000000 D __per_cpu_start 0000000000014280 D __per_cpu_end ffffffffadc001c8 T _stext Signed-off-by: Andy Honig <ahonig@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
480f439c |
|
11-Nov-2013 |
Michal Marek <mmarek@suse.cz> |
kallsyms: Revert back to 128 max symbol length This reverts commits f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and eea0e9c (kbuild: Increase kallsyms max symbol length) except for the added overflow check. The reason is a regression caused by increasing the buffer: http://marc.info/?l=linux-kernel&m=138387700415675. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Joe Mario <jmario@redhat.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
6f62259b |
|
07-Nov-2013 |
Fabio Estevam <fabio.estevam@freescale.com> |
scripts: kallsyms: Use %zu to print 'size_t' Commit f3462aa95 (Kbuild: Handle longer symbols in kallsyms.c) introduced the following warning on ARM: scripts/kallsyms.c:121:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' [-Wformat] Use %zu to print 'size_t'. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
f3462aa9 |
|
23-Oct-2013 |
Andi Kleen <andi@firstfloor.org> |
Kbuild: Handle longer symbols in kallsyms.c Also warn for too long symbols v2: Add missing newline. Use 255 max (Joe Perches) Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
f6537f2f |
|
01-Nov-2013 |
Ming Lei <tom.leiming@gmail.com> |
scripts/kallsyms: filter symbols not in kernel address space This patch uses CONFIG_PAGE_OFFSET to filter symbols which are not in kernel address space because these symbols are generally for generating code purpose and can't be run at kernel mode, so we needn't keep them in /proc/kallsyms. For example, on ARM there are some symbols which may be linked in relocatable code section, then perf can't parse symbols any more from /proc/kallsyms, this patch fixes the problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da) Cc: Russell King <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@vger.kernel.org
|
#
e0a04b11 |
|
30-Apr-2011 |
Xiaochen Wang <wangxiaochen0@gmail.com> |
scripts/kallsyms.c: fix potential segfault Description: This bug hardly appears during real kernel compiling, because the vmlinux symbols table is huge. But we can still catch it under strict condition , as follows. $ echo "c101b97b T do_fork" | ./scripts/kallsyms --all-symbols #include <asm/types.h> ...... ...... .globl kallsyms_token_table ALGN kallsyms_token_table: Segmentation fault (core dumped) $ If symbols table is small, all entries in token_profit[0x10000] may decrease to 0 after several calls of compress_symbols() in optimize_result(). In that case, find_best_token() always return 0 and best_table[i] is set to "\0\0" and best_table_len[i] is set to 2. As a result, expand_symbol(best_table[0]="\0\0", best_table_len[0]=2, buf) in write_src() will run in infinite recursion until stack overflows, causing segfault. This patch checks the find_best_token() return value. If all entries in token_profit[0x10000] become 0 according to return value, it breaks the loop in optimize_result(). And expand_symbol() works well when best_table_len[i] is 0. Signed-off-by: Xiaochen Wang <wangxiaochen0@gmail.com> Acked-by: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
ef894870 |
|
10-Sep-2010 |
Jean Sacren <sakiwit@gmail.com> |
scripts/kallsyms: Enable error messages while hush up unnecessary warnings As no error was handled, we wouldn't be able to know when an error does occur. The fix preserves error messages while it doesn't let unnecessary compiling warnings show up. Signed-off-by: Jean Sacren <sakiwit@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
71d41aed |
|
27-Jan-2010 |
Himanshu Chauhan <hschauhan@nulltrace.org> |
scripts/kallsyms: suppress build warning Suppress a warn_unused_result warning. fgets is called as a part of error handling. It is called just to drop a line and return immediately. read_map is reading the file in a loop and read_symbol reads line by line. So I think there is no point in using return value for useful checking. Other checks like 3 items were returned or !EOF have already been done. Signed-off-by: Himanshu Chauhan <hschauhan@nulltrace.org> Cc: WANG Cong <xiyou.wangcong@gmail.com> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
a9ece53c |
|
22-Sep-2009 |
Paul Mundt <lethal@linux-sh.org> |
kallsyms: fix segfault in prefix_underscores_count() Commit b478b782e110fdb4135caa3062b6d687e989d994 "kallsyms, tracing: output more proper symbol name" introduces a "bugfix" that introduces a segfault in kallsyms in my configurations. The cause is the introduction of prefix_underscores_count() which attempts to count underscores, even in symbols that do not have them. As a result, it just uselessly runs past the end of the buffer until it crashes: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM .tmp_kallsyms1.S /bin/sh: line 1: 16934 Done sh-linux-gnu-nm -n .tmp_vmlinux1 16935 Segmentation fault | scripts/kallsyms > .tmp_kallsyms1.S make: *** [.tmp_kallsyms1.S] Error 139 This simplifies the logic and just does a straightforward count. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Reviewed-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Paulo Marques <pmarques@grupopie.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> [2.6.30.x, 2.6.31.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ac6ca5c8 |
|
15-Jun-2009 |
Mike Frysinger <vapier@gentoo.org> |
kallsyms: fix inverted valid symbol checking The previous commit (17b1f0de) introduced a slightly broken consolidation of the memory text range checking. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
17b1f0de |
|
08-Jun-2009 |
Mike Frysinger <vapier@gentoo.org> |
kallsyms: generalize text region handling Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
028f0426 |
|
10-Jul-2006 |
Robin Getz <robin.getz@analog.com> |
kallsyms: support kernel symbols in Blackfin on-chip memory The Blackfin arch has a discontiguous .text layout due to having on-chip instruction memory and no virtual memory support. As such, we need to add explicit checks for these additional .text regions. Signed-off-by: Robin Getz <robin.getz@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
b478b782 |
|
13-Mar-2009 |
Lai Jiangshan <laijs@cn.fujitsu.com> |
kallsyms, tracing: output more proper symbol name Impact: bugfix, output more reliable symbol lookup result Debug tools(dump_stack(), ftrace...) are like to print out symbols. But it is always print out the first aliased symbol.(Aliased symbols are symbols with the same address), and the first aliased symbol is sometime not proper. # echo function_graph > current_tracer # cat trace ...... 1) 1.923 us | select_nohz_load_balancer(); 1) + 76.692 us | } 1) | default_idle() { 1) ==========> | __irqentry_text_start() { 1) 0.000 us | native_apic_mem_write(); 1) | irq_enter() { 1) 0.000 us | idle_cpu(); 1) | tick_check_idle() { 1) 0.000 us | tick_check_oneshot_broadcast(); 1) | tick_nohz_stop_idle() { ...... It's very embarrassing, it ouputs "__irqentry_text_start()", actually, it should output "smp_apic_timer_interrupt()". (these two symbol are the same address, but "__irqentry_text_start" is deemed to the first aliased symbol by scripts/kallsyms) This patch puts symbols like "__irqentry_text_start" to the second aliased symbols. And a more proper symbol name becomes the first. Aliased symbols mostly come from linker script. The solution is guessing "is this symbol defined in linker script", the symbols defined in linker script will not become the first aliased symbol. And if symbols are found to be equal in this "linker script provided" criteria, symbols are sorted by the number of prefix underscores. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Paulo Marques <pmarques@grupopie.com> LKML-Reference: <49BA06E2.7080807@cn.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
2ea03891 |
|
14-Jan-2009 |
Sam Ravnborg <sam@ravnborg.org> |
Revert "kbuild: strip generated symbols from *.ko" This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483. And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL") 9bb482476c6c9d1ae033306440c51ceac93ea80c These stripping patches has caused a set of issues: 1) People have reported compatibility issues with binutils due to lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2 Reported by: Wenji 2) ccache and distcc no longer works as expeced Reported by: Ted, Roland, + others 3) The installed modules increased a lot in size Reported by: Ted, Davej + others Reported-by: Wenji Huang <wenji.huang@oracle.com> Reported-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: Dave Jones <davej@redhat.com> Reported-by: Roland McGrath <roland@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
9bb48247 |
|
16-Dec-2008 |
Jan Beulich <jbeulich@novell.com> |
allow stripping of generated symbols under CONFIG_KALLSYMS_ALL Building upon parts of the module stripping patch, this patch introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y. Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64) kernels I tested with. The patch also does away with the need to special case the kallsyms- internal symbols by making them available even in the first linking stage. While it is a generated file, the patch includes the changes to scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure here is. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
aab34ac8 |
|
19-May-2008 |
Sam Ravnborg <sam@ravnborg.org> |
kbuild: filter away debug symbols from kernel symbols Andi Kleen <andi@firstfloor.org> reported that he saw a lot of symbols like this: 0000000000000b24 N DW.aio.h.903a6d92.2 0000000000000bce N DW.task_io_accounting.h.8d8de327.0 0000000000000bec N DW.hrtimer.h.c23659c6.0 in his System.map / kallsyms output. Simple solution is to skip all debugging symbols (they are marked 'N'). Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Paulo Marques <pmarques@grupopie.com>
|
#
c6495aaa |
|
30-Apr-2008 |
Bryan Wu <cooloney@kernel.org> |
kallsyms: nuke all ChangeLog, this should be logged by git Pointed out by Paulo: "When I wrote this initially, it was a mistake to add a Changelog in the first place, but I didn't know better at the time. If you're going to make changes to this file, please remove all the Changelog, instead of adding more entries to it. The 'Changelog' should be kept by the version control system, and not the source code itself." Cc: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Acked-by: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f2df3f65 |
|
06-Feb-2008 |
Paulo Marques <pmarques@grupopie.com> |
kallsyms should prefer non weak symbols When resolving symbol names from addresses with aliased symbol names, kallsyms_lookup always returns the first symbol, even if it is a weak symbol. This patch changes this by sorting the symbols with the weak symbols last before feeding them to the kernel. This way the kernel runtime isn't changed at all, only the kallsyms build system is changed. Another side effect is that the symbols get sorted by address, too. So, even if future binutils version have some bug in "nm" that makes it fail to correctly sort symbols by address, the kernel won't be affected by this. Mathieu says: I created a module in LTTng that uses kallsyms to get the symbol corresponding to a specific system call address. Unfortunately, all the unimplemented syscalls were all referring to the (same) weak symbol identifying an unrelated system call rather that sys_ni (or whatever non-weak symbol would be expected). Kallsyms was dumbly returning the first symbol that matched. This patch makes sure kallsyms returns the non-weak symbol when there is one, which seems to be the expected result. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Looks-great-to: Rusty Russell <rusty@rustcorp.com.au> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a3b81113 |
|
06-Feb-2008 |
Robin Getz <rgetz@blackfin.uclinux.org> |
remove support for un-needed _extratext section When passing a zero address to kallsyms_lookup(), the kernel thought it was a valid kernel address, even if it is not. This is because is_ksym_addr() called is_kernel_extratext() and checked against labels that don't exist on many archs (which default as zero). Since PPC was the only kernel which defines _extra_text, (in 2005), and no longer needs it, this patch removes _extra_text support. For some history (provided by Jon): http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019734.html http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019736.html http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019751.html [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jon Loeliger <jdl@freescale.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9281acea |
|
17-Jul-2007 |
Tejun Heo <htejun@gmail.com> |
kallsyms: make KSYM_NAME_LEN include space for trailing '\0' KSYM_NAME_LEN is peculiar in that it does not include the space for the trailing '\0', forcing all users to use KSYM_NAME_LEN + 1 when allocating buffer. This is nonsense and error-prone. Moreover, when the caller forgets that it's very likely to subtly bite back by corrupting the stack because the last position of the buffer is always cleared to zero. This patch increments KSYM_NAME_LEN by one and updates code accordingly. * off-by-one bug in asm-powerpc/kprobes.h::kprobe_lookup_name() macro is fixed. * Where MODULE_NAME_LEN and KSYM_NAME_LEN were used together, MODULE_NAME_LEN was treated as if it didn't include space for the trailing '\0'. Fix it. Signed-off-by: Tejun Heo <htejun@gmail.com> Acked-by: Paulo Marques <pmarques@grupopie.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7c5d249a |
|
20-Jun-2007 |
Paulo Marques <pmarques@grupopie.com> |
kallsyms: remove usage of memmem and _GNU_SOURCE from scripts/kallsyms.c The only in-kernel user of "memmem" is scripts/kallsyms.c and it only uses it to find tokens that are 2 bytes in size. It is trivial to replace it with a simple function that finds 2-byte tokens. This should help users from systems that don't have the memmem GNU extension available. Signed-off-by: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
aad09470 |
|
08-Dec-2006 |
Jan Beulich <jbeulich@novell.com> |
[PATCH] move kallsyms data to .rodata Kallsyms data is never written to, so it can as well benefit from CONFIG_DEBUG_RODATA. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
2c22d8ba |
|
06-Dec-2006 |
Vivek Goyal <vgoyal@in.ibm.com> |
[PATCH] relocatable kernel: Fix kallsyms on avr32 after relocatable kernel changes o On some platforms like avr32, section init comes before .text and not necessarily a symbol's relative position w.r.t _text is positive. In such cases assembler detects the overflow and emits warning. This patch fixes it. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
|
#
fd593d12 |
|
06-Dec-2006 |
Eric W. Biederman <ebiederm@xmission.com> |
[PATCH] relocatable kernel: Kallsyms generate relocatable symbols Print the addresses of non-absolute symbols relative to _text so that ld will generate relocations. Allowing a relocatable kernel to relocate them. We can't actually use the symbol names because kallsyms includes static symbols that are not exported from their object files. Add the _text symbol definitions to the architectures which don't define it otherwise linker will fail. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de>
|
#
f1a136e0 |
|
25-Mar-2006 |
Jesper Juhl <jesper.juhl@gmail.com> |
[PATCH] kallsyms: handle malloc() failure This fixes coverity bugs #398 and #397 Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
6f00df24 |
|
06-Sep-2005 |
Ralf Baechle <ralf@linux-mips.org> |
[PATCH] Strip local symbols from kallsyms Local symbols generated by gcc start with a `$'; no point in including them in the kernel. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
b3dbb4ec |
|
06-Sep-2005 |
Paulo Marques <pmarques@grupopie.com> |
[PATCH] kallsyms: change compression algorithm This patch changes the way the compression algorithm works. The base algorithm is similiar to the previous but we force the compressed token size to 2. Having a fixed size compressed token allows for a lot of optimizations, and that in turn allows this code to run over *all* the symbols faster than it did before over just a subset. Having it work over all the symbols will make it behave better when symbols change positions between passes, and the "inconsistent kallsyms" messages should become less frequent. In my tests the compression ratio was degraded by about 0.5%, but the results will depend greatly on the number of symbols to compress. Signed-off-by: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
61d9cdf2 |
|
15-Jul-2005 |
J.A. Magallon <jamagallon@able.es> |
[PATCH] kbuild: signed char fixes for scripts This time I did not break anything... and they shut up gcc4 ;) Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
075d6eb1 |
|
05-May-2005 |
David Woodhouse <dwmw2@infradead.org> |
[PATCH] ppc32: platform-specific functions missing from kallsyms. The PPC32 kernel puts platform-specific functions into separate sections so that unneeded parts of it can be freed when we've booted and actually worked out what we're running on today. This makes kallsyms ignore those functions, because they're not between _[se]text or _[se]inittext. Rather than teaching kallsyms about the various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers for kallsyms. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
41f11a4f |
|
01-May-2005 |
Yoshinori Sato <ysato@users.sourceforge.jp> |
[PATCH] kallsyms C_SYMBOL_PREFIX support kallsyms does not consider SYMBOL_PREFIX of C. Consequently it does not work on architectures using that prefix character (h8300, v850). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
|