libkldelf: add a private library for kernel/kld-related ELF parsing

[khng]

Summary

The libkldelf library was originally a part of kldxref(8). It exposed
ELF parsing helpers specialized in parsing KLDs and the kernel
executable. The library can be used to read metadata such as linker_set,
mod_depend, mod_version and PNP match info, and raw data from the ELF.

To promote the reuse of the facilities the ELF parsing code is separated
from kldxref(8) into a new private library.

kldxref(8) is modified to link against the libkldelf library.

Sponsored by: Juniper Networks, Inc.

[jhb]

I think it would be easier to review if you moved the files out of kldxref and changed kldxref to use the library as part of this commit. Git might be able to follow history in that case, but with simple copies it is not coping it seems.

[khng]

per jhb@'s suggestion.

[khng]

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

[khng]

Updated to be a private library.

[imp]

Do we need ef_mips.c still ?

[khng]

In D46719#1066014, @imp wrote:

Do we need ef_mips.c still ?

At least not for the upstream FreeBSD I presume.

Ka Ho

[khng]

Fix indentiation issue in mtree files

[khng]

Update Makefile.depend as well.

[markj]

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.

lib/libkldelf/Makefile

16

Does this mean that the header gets installed? Is that appropriate for a private library?

[khng]

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.

Will update the commit message accordingly.

[khng]

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

[markj]

This seems ok to me. Please make sure you test MacOS and Linux builds as well, e.g., with a PR on github.

It would be nice to see the patches for intended consumers (libkvm?) before this lands, though.

lib/libkldelf/Makefile

16

Still wondering about this.

[khng]

Remove include headers installation

[khng]

lib/libkldelf/Makefile

16

Removed. The header is seemingly useless to be installed into usr/include for now.

[markj]

lib/libkldelf/ef_amd64.c

108

Should this case be an error instead?

[khng]

lib/libkldelf/ef_amd64.c

108

I could be wrong, but if we return error here kmods with R_X86_64_IRELATIVE might be an issue.

[markj]

I think @jhb should get a chance to take another look before committing this.

lib/libkldelf/ef_amd64.c

108

Indeed, but it might be good to handle that one separately somehow, e.g., return EOPNOTSUPP and modify callers to handle it.

[emaste]

Overall LGTM

lib/libkldelf/Makefile

7

while here, might as well make these one per line also

lib/libkldelf/ef_amd64.c

108

Agreed, silently ignoring unhandled relocations seems like a bad idea. This can be a followup change though.

[khng]

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