kldxref fails to correctly read most kld files. The reason for this is that kldxref assumes, that the ELF file containes only REL relocation records and that only RELATIVE relocations need to be performed to read the module meta data. If these two assumptions are true, effectively no relocation has to be performed, because the module's load address is 0 in kldxref's case. For sparc64 the first assumptions is certainly false, because sparc64 uses only RELA relocation records. Because of the missing relocation in this case, the code tries to access 0 offsets in the file. Fix: The following patch fixes the problem in the following way: 1. It reads the REL and RELA relocation records. 2. At the places where pointers are accessed in the object file two additional routines are called that look whether relocation records exist for the object file part that is to be red. If there are it applies the relocations. The patch currently handles REL records of type R_I386_RELATIVE and RELA records of type R_SPARC_RELATIVE. Alle other combinations result in a warning message. This means that alpha and ia64 user will probably see warning messages. This can be overcome by either adding the corresponding alpha and ia64 relocation types (R_ALPHA_RELATIVE and R_IA64_REL64LSB (I suppose)) or removing the warning message itself. The entire handling of REL records could be removed, because it effectively is a NOP a.t.m. I suggest leaving it, because if in the future other relocation types refer to the file offsets in question, we will get a warning message. How-To-Repeat: Execute kldxref /boot/kernel and watch the error messages.
Responsible Changed From-To: freebsd-sparc->jake
Responsible Changed From-To: jake->obrien David wants to work on this :-] I created a perforce branch, jake_kldxref, and committed these patches and the patches in pr 46732 to it,
State Changed From-To: open->closed Committed, thanks!