Re: [GIT PULL] x86 fixes

Ard Biesheuvel
2014-09-23T08:18:12Z

On 23 September 2014 09:20, Matt Fleming <matt.fleming@intel.com> wrote:
> On Tue, 2014-09-23 at 07:58 +0200, Ingo Molnar wrote:
>>
>> So if it's the GOT fixup then I feel the safest option is to
>> revert 9cb0e394234d straight away, and then to do a functional
>> revert of f23cf8bd5c1f49 as a separate step, perhaps via
>> something really crude like:
>>
>> #include "../..../drivers/firmware/efi/libstub/efi-stub-helper.c"
>>
>> or so. (Maybe someone else can think of something
>> cleaner/simpler, because this method is really ugly, as we'd have
>> to #include the whole libstub library into eboot.c AFAICS...)
>
> Yeah, I think at this point in the release cycle it would be safest to
> revert back to the original scheme of #including the .c files. I'm not

Agreed

> sure if we can do any better in a robust way, i.e. without introducing
> more regressions. Then take a look at doing the boot stub unification
> with fresh eyes (and improved testing) after v3.17.
>
> What I want to avoid is reverting the arm64 side of things too, so I'm
> gonna take a stab at doing the necessary reverts/partial
> reverts/whatever to get x86 back to the pre-merge window boot stub
> duplicated code scheme.
>

The stub unification was already working fine in 3.16, it is the
libstub cleanup I did that is causing this, so we could revert just
all of that if it makes it easier to get this fixed for the release.

Unless your last patch was incorrect (which I don't think it was), the
only way to solve this conclusively is finding a way (i.e., through
visibility=hidden attributes for efi_early etc) to share those symbols
between .o files without introducing any new GOT entries. Anyone in
team x86 that can shed some light on why hidden globals still generate
GOT entries on 32 bit?

It will be difficult for me to keep up with this thread over the next
days, so I have added Leif and Roy on cc. If you need to make any
changes that affect arm64, they should be able to confirm whether it
causes any problems or not.

Thanks,
Ard.