My point is that existing debuggers already know to extract build-id from PT_NOTE sections in cores, etc. and that it will likely be much simpler to implement support for build-id matching in kgdb (which I maintain) if we just ensure the note is memory-resident vs adding a custom entry in the linker_files linked list. Probably it would be worth while building the debugger side out in either lldb or gdb to validate the kernel changes.

It is far worse though, we can't find the linker_files linked list in a crash dump without already having the correct kernel to find the linker_files and related symbols, so this change doesn't really add anything useful that I can see. At least, I don't believe we are currently including the kernel's build-id in the minidump header (and it doesn't end up in the /var/crash/info.X file). That's probably the first thing to address in some way.

We should do this via normal ELF and not invent new ways to store the build-id. The build-id should already be memory-resident for the link_elf.c case. What we really should be doing is storing the build-id for the kernel as a .note in the crash dump. We should also probably just be treating the .note as memory-resident for .o files (if not already, Mark suggested they are already memory-resident), and kgdb can look for the build-id that way rather than digging around in the linker_files TAILQ.

One of my suggestions didn't get added and I have to add a dummy comment to add it.

Generally looks good to me.

In D45461#1036800, @imp wrote:

Is this a good place to add a brief note about why this is a good idea, either in the commit message or in the code? (If so, I'd lean towards the former).

After rebasing this on top of the series to rescan on reconnect, this now works as desired, so I will keep it at as CAM_DEV_NOT_THERE but push the rescan on reconnect fixes first.

Apply the fix from D45433

I was able to test this by loading if_cxlv on a host after enabling iov (no need for bhyve to be involved). This version works fine for me now for that test and should also work for bhyve.

Pass right device_t for map/unmap resource

Can you please add IOMMU to arm64 NOTES?

In D45279#1033131, @markj wrote:

Why would openssl return an error?

I wonder if this would be useful on risc64 which has similar issues. There I have been trying (but not succeeding) to get GCC's libatomic.a to build and install as part of the freebsdN-gcc ports so that it could be linked to.

In D36754#1031820, @mmel wrote:

Hmm, shouldn't the -masm-syntax-unified be added to gcc CFLAGS? (just guessing, untested)

FYI, I did tweak a few style things when pushing: 1) I moved the new extern variable declaration down next to the one other extern variable in the header (and in general type definitions are first before externs), and in kern_linker.c I rewrapped a few lines to fit in 80 cols.

Only amd64 and i386 successfully build with GCC currently. risc-v needs GCC's libatomic to link, powerpc and arm break in various ways. There's a reason that only amd64 GCC builds are enabled in CI. The toolchains do exist for all of our platforms, but getting things to build there is more of an aspiration.