I think this isn't really the right way to fix this. The kernel linker knows the full path to the module and that is what kgdb uses to figure out where modules live (and they might not be in the module path at all if you have done 'make load' from a module build directory, or they could be in a "later" path in the module path if the user uses an absolute path with kldlad). pmcstat should be using the full path (though that might require fixing the pmcstat messages if pmcstat is relying on those rather than this.

It looks like pmc_kld_load() just needs to use 'lf->pathname' instead of 'lf->filename'. You could then change the path logic to do something like this:

if (image->pi_iskernelmodule && strchr(path, '/') == NULL)
    (void) snprintf(...);
else
    (void) snprintf(...);

That would then honor FSROOT, but otherwise use the pathname of the actual-loaded image (so once pmc.ko is fixed kernel modules would use full paths and could use the 'user' case of just adding the FSROOT prefix, and the other hack would only remain for legacy kernels).

Yay for this change!

And, yes, @jhb probably has a more robust solution, for reasons he states (e.g. modules that a user kldloads from a custom place).

In D8234#171288, @jhb wrote:

I think this isn't really the right way to fix this. The kernel linker knows the full path to the module and that is what kgdb uses to figure out where modules live (and they might not be in the module path at all if you have done 'make load' from a module build directory, or they could be in a "later" path in the module path if the user uses an absolute path with kldlad). pmcstat should be using the full path (though that might require fixing the pmcstat messages if pmcstat is relying on those rather than this.

It might (or might not) be relevant to Juniper that chroots might mess up reliance on the "full path" from the kernel's perspective.

In D8234#171524, @jtl wrote:

Yay for this change!

And, yes, @jhb probably has a more robust solution, for reasons he states (e.g. modules that a user kldloads from a custom place).

In D8234#171288, @jhb wrote:

I think this isn't really the right way to fix this. The kernel linker knows the full path to the module and that is what kgdb uses to figure out where modules live (and they might not be in the module path at all if you have done 'make load' from a module build directory, or they could be in a "later" path in the module path if the user uses an absolute path with kldlad). pmcstat should be using the full path (though that might require fixing the pmcstat messages if pmcstat is relying on those rather than this.

It might (or might not) be relevant to Juniper that chroots might mess up reliance on the "full path" from the kernel's perspective.

It might be relevant, since we use the init_chroot option in loader.conf and pre-load some kernel modules from loader.

I'll experiment with it some before sending an updated diff to this review.

Note that we probably need to have a wider discussion about what the kernel records for paths when one is using init_chroot. As it stands, anything that is recorded before the chroot usually is no longer accurate once the chroot occurs.