linker: expose symbol and string table sections of elf_file

[khng]

Summary

These exposed part could be consumed by libkvm easily to look for
symbols in a vmcore.

Sponsored by: Juniper Networks, Inc.

[markj]

These exposed part could be consumed by libkvm easily to look for symbols in a vmcore.

Could you please explain further? libkvm should have access to the kernel and KLD binaries, why does it need to inspect symbol tables in a vmcore?

sys/kern/link_elf.c

91

Why did const get dropped?

sys/sys/_linker_elf_file.h

39

This header is not very useful without a definition of struct linker_file, which kind of defeats the usual reason for this style of header file.

[khng]

In D46537#1060911, @markj wrote:

These exposed part could be consumed by libkvm easily to look for symbols in a vmcore.

Could you please explain further? libkvm should have access to the kernel and KLD binaries, why does it need to inspect symbol tables in a vmcore?

Which in case of non-live kvm_open() libkvm does not call into kldsym(2). Currently we do not populate the linker_files list in the vmcore. In this scenario usually callers call the kvm_open function with a vmcore and a kernel ELF binary path, so libkvm will never have knowledge of the loaded modules.

[markj]

In D46537#1060919, @khng wrote:

In D46537#1060911, @markj wrote:

These exposed part could be consumed by libkvm easily to look for symbols in a vmcore.

Could you please explain further? libkvm should have access to the kernel and KLD binaries, why does it need to inspect symbol tables in a vmcore?

Which in case of non-live kvm_open() libkvm does not call into kldsym(2). Currently we do not populate the linker_files list in the vmcore. In this scenario usually callers call the kvm_open function with a vmcore and a kernel ELF binary path, so libkvm will never have knowledge of the loaded modules.

I do not follow the bit about "populating the linker_files list". The list should certainly be in the vmcore, that's how kgdb is able to figure out which KLDs were loaded.

[khng]

In D46537#1060920, @markj wrote:

In D46537#1060919, @khng wrote:

In D46537#1060911, @markj wrote:

These exposed part could be consumed by libkvm easily to look for symbols in a vmcore.

Could you please explain further? libkvm should have access to the kernel and KLD binaries, why does it need to inspect symbol tables in a vmcore?

Which in case of non-live kvm_open() libkvm does not call into kldsym(2). Currently we do not populate the linker_files list in the vmcore. In this scenario usually callers call the kvm_open function with a vmcore and a kernel ELF binary path, so libkvm will never have knowledge of the loaded modules.

I do not follow the bit about "populating the linker_files list". The list should certainly be in the vmcore, that's how kgdb is able to figure out which KLDs were loaded.

It does, but libkvm never walks through the list in the first place when kvm_open()-ing against minidump targets, unlike kgdb.

sys/kern/link_elf.c

91

oops.

[khng]

Or, I might just do it the way like how other debugger does - not using elf_file but doing adjustments with only ELF parsing libraries rather.

[markj]

In D46537#1060924, @khng wrote:

Or, I might just do it the way like how other debugger does - not using elf_file but doing adjustments with only ELF parsing libraries rather.

As discussed elsewhere, I'd prefer to have libkvm walk the linker_files list and locate the corresponding binaries, like kgdb does. This way we avoid growing the kernel ABI.

[jhb]

I'm also not sure what the end goal is here? Is it to have libkvm resolve symbols in loaded modules by name via kvm_nlist*() when looking at a crash dump?

[khng]

In D46537#1063010, @jhb wrote:

Is it to have libkvm resolve symbols in loaded modules by name via kvm_nlist*() when looking at a crash dump?

Yep.