Re: [RFT PATCH] efi/x86: move x86 back to libstub

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

 



On 10 October 2014 10:30, Maarten Lankhorst
<maarten.lankhorst@xxxxxxxxxxxxx> wrote:
> Hey,
>
> On 10-10-14 08:35, Ard Biesheuvel wrote:
>> On 6 October 2014 13:06, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>>> This reverts commit 84be880560fb, which itself reverted my original
>>> attempt to move x86 from #include'ing .c files from across the tree
>>> to using the EFI stub built as a static library.
>>>
>>> The issue that affected the original approach was that splitting
>>> the implementation into several .o files resulted in the variable
>>> 'efi_early' becoming a global with external linkage, which under
>>> -fPIC implies that references to it must go through the GOT. However,
>>> dealing with this additional GOT entry turned out to be troublesome
>>> on some EFI implementations. (GCC's visibility=hidden attribute is
>>> supposed to lift this requirement, but it turned out not to work on
>>> the 32-bit build.)
>>>
>>> Instead, use a pure getter function to get a reference to efi_early.
>>> This approach results in no additional GOT entries being generated,
>>> so there is no need for any changes in the early GOT handling.
>>>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
>>> Cc: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx>
>>> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>>> ---
>>>
>>> Gents,
>>>
>>> This is a request for testing: I would like to find out if this patch
>>> fixes Maarten's issue without breaking anything like it did for Josh
>>> and Linus the first time around.
>>>
>>
>> Any takers?
> Sorry it was on my todo list but I lost access to my laptop for a while.
> Normal EFI boot through refind works at least, but I think netboot may use a slightly
> different codepath which I can't test right now.
>
> Tested-By: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>

Thanks! So I suppose the code path you did test is the code path that
produced the failure last time?
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux