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

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>

show more ...

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 '.' r

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>

show more ...

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@kerne

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>

show more ...

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>

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

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>

show more ...

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 comment

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>

show more ...

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_s

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>

show more ...

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 "

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>

show more ...

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 kalls

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>

show more ...

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: Masah

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>

show more ...

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 d

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>

show more ...

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 workaroun

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>

show more ...

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

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>

show more ...

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 s

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>

show more ...

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, wh

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>

show more ...

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
comp

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>

show more ...

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 s

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>

show more ...

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 <ma

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>

show more ...

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

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>

show more ...

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:

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>

show more ...

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, ther

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>

show more ...

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 on

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>

show more ...

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 sing

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>

show more ...

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 <stappe

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>

show more ...

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

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

show more ...