Op 04-09-14 om 13:19 schreef Ard Biesheuvel: > >> On 4 sep. 2014, at 12:48, Maarten Lankhorst >> <maarten.lankho...@canonical.com> wrote: >> >> Op 03-09-14 om 21:57 schreef Ard Biesheuvel: >>> On 3 September 2014 19:59, Matt Fleming <m...@console-pimps.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
