From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vnoeo-0004cK-75 for mharc-grub-devel@gnu.org; Tue, 03 Dec 2013 07:00:50 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnoeg-0004Y1-UO for grub-devel@gnu.org; Tue, 03 Dec 2013 07:00:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vnoeb-0002t2-HE for grub-devel@gnu.org; Tue, 03 Dec 2013 07:00:42 -0500 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:38590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnoeb-0002sn-68 for grub-devel@gnu.org; Tue, 03 Dec 2013 07:00:37 -0500 Received: by mail-ee0-f53.google.com with SMTP id b57so1416688eek.12 for ; Tue, 03 Dec 2013 04:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=DBovDyig8zzGn8M0cOecDTG7DKe43AYZxukTAT2dZyg=; b=HQg/AcrW8/fWD5EjbWctzC4qoo/PLluN8F89nwl4IOP5kMSfz8I/0quZW6pcuKV50V +dAaExrLod/BxiMnDAFZqhe6ShWyEWIUSYKgrkWtHOiUOFM8uqwsfaqzLvZKyRBW2aBX QyS93rvdonUklvbAE7G+NJrPrTtzs05v+1kc2k1fCc41zngehi/kuuFZHgrKC82RJrAO iY2qnc/zip+1JsZoxfO4G6N8s9iCsDBvrcvP7iYWZR7bpHxDKR89zs7Zupwej+m2tKOa c06PCUeJf8kqO3RgncBQKPk0wtoDOUqcx2qn9j/tx/z7AXV0WD8h4h0ci+G5SwAlrNUJ 3QJg== X-Received: by 10.14.69.200 with SMTP id n48mr6111764eed.54.1386072036301; Tue, 03 Dec 2013 04:00:36 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id h48sm81596161eev.3.2013.12.03.04.00.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 04:00:35 -0800 (PST) Message-ID: <529DC7E2.3080307@gmail.com> Date: Tue, 03 Dec 2013 13:00:34 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH, RFC, RFT] ARM relocation fixes References: <20131202133051.GE24997@rocoto.smurfnet.nu> <529CC74C.2060903@gmail.com> <20131202194020.GN24997@rocoto.smurfnet.nu> <529CE7DF.6000906@gmail.com> <20131202204622.GO24997@rocoto.smurfnet.nu> <529D6E1D.3010806@gmail.com> <20131203081441.GR24997@rocoto.smurfnet.nu> <529D94E0.3060402@gmail.com> <20131203084730.GS24997@rocoto.smurfnet.nu> <529DA4E1.8050201@gmail.com> <20131203111609.GT24997@rocoto.smurfnet.nu> In-Reply-To: <20131203111609.GT24997@rocoto.smurfnet.nu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2DMHEASDFNTHRONGXGQWP" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::235 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 12:00:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DMHEASDFNTHRONGXGQWP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03.12.2013 12:16, Leif Lindholm wrote: > On Tue, Dec 03, 2013 at 10:31:13AM +0100, Vladimir '=CF=86-coder/phcode= r' Serbinenko wrote: >>>> I meant that you can use conditions with bl but not blx. So if we ha= ve a >>>> reloc on ARM bl.e targetting Thumb then we have to add veneers. Sinc= e we >>>> have only small number of interworking calls it's probably easier to= >>>> always add veneers on interworking relative relocations rather than >>>> having micro-optimisation and get some minor case wrong. >>> >>> OK, but the only place we could ever have a problem with this would >>> be if we had asm in the kernel _explicitly_ done as .thumb. >>> Which we don't. We explicitly moved away from that in order to have >>> support for pre-v7 processors. >>> >> We also call C code from asm. One such instance (for division >> instructions) caused the problem >>> All modules will have full 32-bit external references, so will not >>> use these instructions anyway. Any internal references within modules= >>> will be linked with LD, which will fix this up automatically. >>> >> In my small test I compiled: >> extern void g(void); >> >> void f (int x) >> { >> if (!x) >> g(); >> } >> And got following assembly with -Os: >> >> 0: e3500000 cmp r0, #0 >> 4: e92d4008 push {r3, lr} >> 8: 0bfffffe bleq 0 >> 8: R_ARM_JUMP24 g >> c: e8bd4008 pop {r3, lr} >> 10: e12fff1e bx lr >> >> If g is a function in thumb kernel or thumb module then you need a ven= eer. >=20 > Ok, you got me. Didn't consider -Os. > But the second case would still be auto-added by the linker. >=20 LD in -r mode doesn't always resolve all relocs > But what is the objection to -mlong-calls? >=20 Originally it was from my experiments with clang. It doesn't accept -mlong-calls. But clang isn't enough of motivation for this complexity, far from it. My motivation is to have a robust dynamic linker with interwork possibilities, that we won't have to rewrite when new compiler changes behaviour or if we decide to decrease the requirement to armv4. I think, I'll make build system add -mlong-calls if it's supported by compiler. > My armv7 kernel ends up only slightly larger with this option (57272 > bytes vs. 57088) - 184 bytes, from which 12 bytes per veneer can be > subtracted. And the overall arm-efi directory is smaller (10031244 vs. > 10254924). For just the *.mod too (1229498 vs. 1234034). >=20 > When compiling for For ARM (A32) (i.e. armv6), there is no difference > in kernel size, but modules do grow 1.8% from 1477726 to 1503986. I'm confused by numbers: I don't see which ones relate to which configs (long-calls/no-long-calls A32/T16/T32) > But is it really worth adding complexity to grub-mkimage for a small > benefit to legacy platforms only? Could we instead add an arm_cflags > with -mlong-calls for kernel in Makefile.core.def? >=20 > / > Leif >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2DMHEASDFNTHRONGXGQWP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlKdx+IACgkQmBXlbbo5nOt88wD/bi3h0/BYlR8HeclYH1qU3EYT wl+aVmy2c0l81eozfBQA/3oJ2FtQe1QbhJmCWbmTxwgSvMSyxjwHt+m8D2w1NWC7 =Ci6z -----END PGP SIGNATURE----- ------enig2DMHEASDFNTHRONGXGQWP--