Date: Sat, 18 Aug 2018 10:23:27 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: sgk@troutmask.apl.washington.edu Cc: Ed Maste <emaste@freebsd.org>, Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: kldref: unhandled relocation type 2 Message-ID: <C2E89211-755A-4358-B8F4-9E31106D754E@FreeBSD.org> In-Reply-To: <20180817225012.GA92976@troutmask.apl.washington.edu> References: <20180808165819.GA87623@troutmask.apl.washington.edu> <CANCZdfp7pcpNjsmdGDYUaxm6j6tkr9Y5JWqq7VAQ7jBezh8cCw@mail.gmail.com> <20180808171936.GA87930@troutmask.apl.washington.edu> <CANCZdfq=ToZ6oS=dsZ_8n5R5JNLpejpv%2Bb8=GyoytY5g_8YDkw@mail.gmail.com> <CAPyFy2C46ianx_V36gPR9fM=9-GzbrbFnaeiBrzDn9Q3nVy70Q@mail.gmail.com> <20180817225012.GA92976@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_760CC6BA-0C07-452E-B6F7-4B069B48BB2F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 18 Aug 2018, at 00:50, Steve Kargl <sgk@troutmask.apl.washington.edu> =
wrote:
>=20
> On Fri, Aug 17, 2018 at 05:50:06PM -0400, Ed Maste wrote:
>> On 8 August 2018 at 13:27, Warner Losh <imp@bsdimp.com> wrote:
>>>=20
>>>> % /usr/obj/usr/src/i386.i386/usr.sbin/kldxref/kldxref /boot/kernel
>>>> kldxref: unhandled relocation type 2
>>>> (40+ messages...)
>>>=20
>>>=20
>>> 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...
>>=20
>> 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.
>=20
> 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- usr.sbin/kldxref/ef_i386.c (revision 337959)
+++ usr.sbin/kldxref/ef_i386.c (working copy)
@@ -82,11 +82,17 @@ ef_reloc(struct elf_file *ef, const void *reldata,
addr =3D (Elf_Addr)addend + relbase;
*where =3D addr;
break;
- case R_386_32: /* S + A - P */
+ case R_386_32: /* S + A */
addr =3D EF_SYMADDR(ef, symidx);
addr +=3D addend;
*where =3D addr;
break;
+ case R_386_PC32: /* S + A - P */
+ addr =3D EF_SYMADDR(ef, symidx);
+ addr +=3D addend;
+ addr -=3D (Elf_Addr)where;
+ *where =3D addr;
+ break;
case R_386_GLOB_DAT: /* S */
addr =3D EF_SYMADDR(ef, symidx);
*where =3D addr;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
--Apple-Mail=_760CC6BA-0C07-452E-B6F7-4B069B48BB2F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW3fXfwAKCRCwXqMKLiCW
oyigAJwIrcLp60pZvbYwbaxsL22a9KcNvQCgvF1GP4UBLaQz1ehbpFNWAZFLwKQ=
=wBDN
-----END PGP SIGNATURE-----
--Apple-Mail=_760CC6BA-0C07-452E-B6F7-4B069B48BB2F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C2E89211-755A-4358-B8F4-9E31106D754E>