On 18 Aug 2018, at 00:50, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote: > > On Fri, Aug 17, 2018 at 05:50:06PM -0400, Ed Maste wrote: >> On 8 August 2018 at 13:27, Warner Losh <imp_at_bsdimp.com> wrote: >>> >>>> % /usr/obj/usr/src/i386.i386/usr.sbin/kldxref/kldxref /boot/kernel >>>> kldxref: unhandled relocation type 2 >>>> (40+ messages...) >>> >>> >>> Oh, wait: relocation type, not module info.... That's not me, that's ed and >>> the new linker I think, or Dimitry and the new clang... >> >> 2 is R_386_PC32. It looks like the kernel's relocation code handles >> this, but not kldxref. I hope to be able to look at it soon. > > Thanks, Ed. If you need any other information, just ask. This rabbit hole is a bit deeper though. Almost all .ko files in /boot/kernel contain R_386_PC32 relocations: $ for i in /boot/kernel/*.ko; do readelf -r $i | grep -q R_386_PC32 && echo $i; done | wc -l 861 But kldxref *only* complains specifically about if_bge.ko, and it is not clear to me why. Maybe the R_386_PC32 relocations are first preprocessed away, somehow, before they end up in kldxref's ef_reloc(), where the "unhandled relocation type" warning is produced? In any case, I tried the following patch, which at least makes the warning go away, but might not be the right solution: Index: usr.sbin/kldxref/ef_i386.c =================================================================== --- usr.sbin/kldxref/ef_i386.c (revision 337959) +++ usr.sbin/kldxref/ef_i386.c (working copy) _at__at_ -82,11 +82,17 _at__at_ ef_reloc(struct elf_file *ef, const void *reldata, addr = (Elf_Addr)addend + relbase; *where = addr; break; - case R_386_32: /* S + A - P */ + case R_386_32: /* S + A */ addr = EF_SYMADDR(ef, symidx); addr += addend; *where = addr; break; + case R_386_PC32: /* S + A - P */ + addr = EF_SYMADDR(ef, symidx); + addr += addend; + addr -= (Elf_Addr)where; + *where = addr; + break; case R_386_GLOB_DAT: /* S */ addr = EF_SYMADDR(ef, symidx); *where = addr; =================================================================== While here, I corrected the comment for R_386_32 relocations. At least, all the documentation I could find states that such relocations only add the addend to the symbol, and the actual code also does that. -Dimitry
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC