On 18/05/18 18:56, Nick Desaulniers wrote: > + Andrey > > On Fri, May 18, 2018 at 10:45 AM Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> On 18/05/18 18:40, Nick Desaulniers wrote: >>> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@xxxxxxx> > wrote: >>>> I'm going to ask the question I've asked before when this patch cropped >>>> up (must be the 4th time now): > > The previous threads for context: > https://patchwork.kernel.org/patch/10060381/ > https://lkml.org/lkml/2018/3/16/434 > >>>> Is it guaranteed that this is the only case where LLVM/clang is going > to >>>> generate absolute addresses instead of using relative addressing? >>> >>> It seems like if there's requirements that only relative addressing be >>> used, then the compiler should be told explicitly about this > restriction, >>> no? > >> Certainly. What's the rune? > > It seems like -fno-jump-tables covers all known issues and unblocks people > from doing further work. It sounds like you'd like some kind of stronger > guarantee? Wont those cases still "crop up" as far as needing to annotate > either the code, or build scripts? What I'd really like is to apply that patch knowing that: - you have checked that with a released version of the compiler, you don't observe any absolute address in any of the objects that are going to be executed at EL2 on a mainline kernel, - you have successfully run guests with a mainline kernel, - it works for a reasonable set of common kernel configurations (defconfig and some of the most useful debug options), - I can reproduce your findings with the same released compiler. Is that the case? I don't think any of the above is completely outlandish. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
