From owner-freebsd-hackers@freebsd.org Mon Feb 19 03:22:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA626F21B2F for ; Mon, 19 Feb 2018 03:22:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic315-10.consmr.mail.gq1.yahoo.com (sonic315-10.consmr.mail.gq1.yahoo.com [98.137.65.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0517C92F for ; Mon, 19 Feb 2018 03:22:26 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: rSTg3mgVM1m7HaxLQ9r89wlxSmROF2MIcqLwvCzp5dP78nSf.0VQl4FZGQ5oQ9b 2BfPMW75hNoEolMbezcG.LxS_xLUd29Py_v.6M3x_PdFWazD0IjgYeRbAElLx0ryJJefREc39fKW RvKFEzNVK5HHDBvI9baZ2OQtP_IRGmlGRH_ov9j1jyK9WhzJa8ewW9d.Lqj5FuDscNlohVSxJt0W mT8Qq_joFAUGL1ig_mhsp9xl4OIgTk435Ht77cPFuj8yCSxhHJtL_NYb9QnJyLht4OKuKMAMtarX xueaohgrumHEXnRcm9QKFlYVwaLukfGc4YGFR5DH2StCZcRnnNsmZQ.tGLxWuwzq_G1M2Vz272Ub 6cSpFZr6nl36gZc7ntqiBkGv0K9gTH_m8mGoGh4ng277C6lc4LletN0q5MylVA7z9nIUZS5tEL3A W0CbqwaapNNe.icRyOc1xWHUmifR1aK4POIMivQZIXMrnX1azBxS27KR15iIRothxxw2E Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Feb 2018 03:22:20 +0000 Received: from smtpgate101.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.214.169.33]) by smtp402.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 04ab64547a3d5dda105e3784a99041b0; Mon, 19 Feb 2018 03:12:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one? (Still true of clang 6.) From: Mark Millard In-Reply-To: <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> Date: Sun, 18 Feb 2018 19:12:11 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <6F547F69-2821-40D3-AD89-6481F576C6EF@yahoo.com> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> To: Ed Maste , Dimitry Andric X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 03:22:28 -0000 [Notes on clang 6 properties for this. Also note: newer Email address than the original.] On 2017-Dec-29, at 4:18 PM, Mark Millard wrote: > I've not been able to figure out if I should submit something > into llvm's bugzilla for the powerpc64 switching to .rela.plt > and R_PPC64_JMP_SLOT for kernel modules from the earlier > .rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel > modules. (I do not know if powerpc would also have the issue > since other things have been stopping that build for a long > time.) >=20 > Do one or more of you have a clue? >=20 > Reminder: >=20 >=20 > I have submitted FreeBSD bugzilla 224561 for the issue. >=20 > The difference in the likes of filemon.ko > produced by system clang 5.0.1 vs. > devel/powerpc64-xtoolchain-gcc is. . . >=20 > clang 5.0.1: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 = copyinstr + 0 > 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 > . . . I finally did some updating of part of my FreeBSD environment, jumping something like 2000 revision numbers . . . Under head -r329542 and its clang 6 there is still a "Relocation section with addend (.rela.plt)" that uses R_PPC64_JMP_SLOT r_types. (This is using devel/powerpc64-binutils .) (There was and is some .rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64 use as well.) So: 6 is like 5.0.1 for this issue. > vs. >=20 > devel/powerpc64-xtoolchain-gcc: >=20 > Relocation section with addend (.rela.dyn): > r_offset r_info r_type st_value st_name = + r_addend > 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 > 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + = 145b0 > . . . > 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent = + 0 > 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Under head -r329542 devel/powerpc64-gcc there is no use of .rela.plt or R_PPC64_JMP_SLOT: Just .rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64 use. (This is using devel/powerpc64-binutils .) > Apparently R_PPC64_JMP_SLOT is mishandled > and does not explicitly lead to rejection > of the attempted dynamic load. >=20 > It might be an issue if .rela.plt and > R_PPC64_JMP_SLOT should even be generated > instead of .rela.dyn and R_PPC64_RELATIVE > and R_PPC64_ADDR64. I have not actually tried the modern builds on a old PowerMac G5 yet: other things took up time. Also the USB devmatch issues are a worry since I have no alternatives to directly connected USB keyboards, mice (and possibly more) if I end up unable to connect over the local network for some reason. But I've not noticed anything go by that indicated adding support for R_PPC64_JMP_SLOT or .rela.plt in filemon.ko or other such .ko's. So I only expect dynamic module loading to work for the devel/powerpc64-gcc based kernel. (I still build-in two(?) extra .ko's to avoid the loading issue for them if I play with the clang based kernel. One of them is filemon.ko .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late)