@phil for a confirmation as well.

Separate SHT_INIT_ARRAY/SHT_FINI_ARRAY/SHT_X86_64_UNWIND out.

Remove duplicated fsanitize flags during module build

In D47383#1081811, @jhb wrote:

We can probably just do this all the time without needing the flag? I think kldxref just doesn't care, or more likely ef_object.c in kldxref wasn't updated when the kernel linker changed.

Addresses jhb@'s comments

Updated to adapt to NOSAN's introduction

Comments update.

Oops.

Fix per markj@'s comment. ef_print_phdr related part now is left unchanged for now.

Bootstrap it everytime, and remove the __FreeBSD_version bump as well given this library is private.

Remove include headers installation

Update commit message. If it is not reflected on Phabricator I will do it one more time.

In D46719#1066156, @markj wrote:

This is missing some description of libkldelf's intended functionality, either in the commit message or in a man page (maybe a man page is not required for private libraries). It's hard to tell at a glance what this library does, at least for me who is not familiar with kldxref internals.

I don't have any objection to the change itself, it seems fine and will be useful for debuggers and related tools. libdtrace might be able to take advantage of it as well, replacing some existing code.

Update Makefile.depend as well.

Fix indentiation issue in mtree files

In D46719#1066014, @imp wrote:

Do we need ef_mips.c still ?

Updated to be a private library.

I think I have to make it PRIVATELIB to be more useful.

Superseded by D46719.

per jhb@'s suggestion.

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?

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.

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.

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?

Or that can be addressed by malloc_usable_size() ?

Or you probably want to expose a proper API rather?