Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

[Maarten Lankhorst]

Op 04-09-14 om 13:19 schreef Ard Biesheuvel:
>
>> On 4 sep. 2014, at 12:48, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> wrote:
>>
>> Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
>>> On 3 September 2014 19:59, Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote:
>>>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>>>>> Will do, thanks.
>>>>>
>>>>> @Matt: so there is two ways to fix this, the patch above addressing
>>>>> this single instance, and alternatively, adding a #pragma GCC
>>>>> visiblilty push(hidden) to all .c files under libstub/, *before* the
>>>>> #includes. The latter would catch future problems regarding newly
>>>>> introduced global variables, but it may be a bit overkill in this
>>>>> case, as libstub is not expected to be in flux in the foreseeable
>>>>> future.
>>>>>
>>>>> Any preferences?
>>>> Any reason we can't reuse the existing GOT fixup code in the early x86
>>>> boot code? We're not executing it before the EFI boot stub atm, which is
>>>> the reason Maarten is hitting these difficulties.
>>> I guess that is likely to work, I just wasn't aware it existed :-)
>>> I think adding another visibility(hidden) attribute or 2 would
>>> complete eliminate the need for GOT fixups, but I guess that is more
>>> sensitive to compiler versions being recent enough etc.
>>> The attached (build tested only) patch eliminates all GOT relocations
>>> under boot/compressed for a 64-bit EFI stub build.
>>>
>>>> Maarten, does the following help?
>>>>
>>>> If not, Ard please go ahead with option #2 above. Overkill yes, but I've
>>>> done the single __attribute__() hacks in other projects and someone
>>>> (usually me) always eventually forgets to tag some instance.
>>> It appears we just got lucky on arm64, since we don't have any global
>>> variables, but the issue does exist there as well.
>> FWIW, visibility pushing doesn't seem to work for functions declared with extern.
> Are you sure you are seeing GOT entries being generated for functions? Normally, these are resolved via PLT entries, and those usually don't result in GOT entries to be allocated unless the branch target is unknown at link time.
>
No not really, I was just looking at GOTPCREL for the .o files, no idea if they resulted in any actual relocations or not.

~Maarten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/