[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH, RFC, RFT] ARM relocation fixes

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH, RFC, RFT] ARM relocation fixes
Date: Tue, 03 Dec 2013 09:22:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 03.12.2013 09:14, Leif Lindholm wrote:
> On Tue, Dec 03, 2013 at 06:37:33AM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>>> No, BLX immediate has been supported since ARMv5T.
>>> (Yes, that is effectively a 32-bit encoding in what is a 16-bit
>>> instruction set - but so is the basic BL.)
>> I've looked through encoding of those instructions and see how much it's
>> a mess. b* and b*x don't have similar set of options which makes
>> validating them a difficult error-prone task. So I think, I'll just add
>> veneers to mkimage, just like we do on ia64 (either by making a
>> pc-relative variant of veneers or adding fixup for them)
> Not B, BL.
> There is a 1-bit range difference between Thumb BL and BLX, which we
> need to check for anyway. This check already exists (and must exist) in
> the code. Adding veneers would be pure overhead.
I meant that you can use conditions with bl but not blx. So if we have a
reloc on ARM bl.e targetting Thumb then we have to add veneers. Since 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.
> /
>     Leif
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]