On 23 September 2014 09:20, Matt Fleming <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
