linux-toradex.git/scripts/kallsyms.c, branch v6.0-rc7

scripts/kallsyms: update usage message of the kallsyms program

2022-05-27T06:51:48+00:00

The kallsyms program supports --absolute-percpu option but does not display
it in the usage message, fix it.

Signed-off-by: Yuntao Wang 
Signed-off-by: Masahiro Yamada

KVM: arm64: Symbolize the nVHE HYP addresses

2022-04-28T19:53:13+00:00

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: [] __kvm_nvhe_overflow_stack+0x8/0x34!

Signed-off-by: Kalesh Singh 
Tested-by: Fuad Tabba 
Reviewed-by: Fuad Tabba 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20220420214317.3303360-7-kaleshsingh@google.com

kallsyms: ignore all local labels prefixed by '.L'

2022-02-21T15:44:16+00:00

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 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada

kallsyms: fix nonconverging kallsyms table with lld

2021-02-05T08:53:28+00:00

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 
Signed-off-by: Masahiro Yamada

scripts/kallsyms: skip ppc compiler stub .long_branch. / .plt_branch.

2020-09-24T15:41:54+00:00

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 
Signed-off-by: Masahiro Yamada 
Tested-by: Guenter Roeck

KVM: arm64: Add build rules for separate VHE/nVHE object files

2020-07-05T17:37:55+00:00

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 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200625131420.71444-4-dbrazdil@google.com

gcc-10 warnings: fix low-hanging fruit

2020-05-04T16:16:37+00:00

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

scripts/kallsyms: fix wrong kallsyms_relative_base

2020-03-19T14:40:20+00:00

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 
Signed-off-by: Masahiro Yamada

scripts/kallsyms: fix memory corruption caused by write over-run

2020-02-10T20:18:09+00:00

memcpy() writes one more byte than allocated.

Fixes: 8d60526999aa ("scripts/kallsyms: change table to store (strcut sym_entry *)")
Reported-by: youling257 
Reported-by: Pavel Machek 
Signed-off-by: Masahiro Yamada 
Tested-by: Pavel Machek

scripts/kallsyms: change table to store (strcut sym_entry *)

2020-02-03T16:54:30+00:00

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