[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 10:31:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 |
On 03.12.2013 09:47, Leif Lindholm wrote:
> On Tue, Dec 03, 2013 at 09:22:56AM +0100, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>>>> 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.
>
> 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 <g>
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 veneer.
> /
> Leif
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
signature.asc
Description: OpenPGP digital signature
- Re: [PATCH, RFC, RFT] ARM relocation fixes, (continued)
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/02
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes,
Vladimir 'φ-coder/phcoder' Serbinenko <=
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/03
- Re: [PATCH, RFC, RFT] ARM relocation fixes, Leif Lindholm, 2013/12/03