Messages in this thread | | | From | "H.J. Lu" <> | Date | Fri, 16 Jun 2017 09:17:19 -0700 | Subject | Re: xgetbv nondeterminism |
| |
On Fri, Jun 16, 2017 at 9:01 AM, Andy Lutomirski <luto@kernel.org> wrote: > On Thu, Jun 15, 2017 at 9:34 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Thu, Jun 15, 2017 at 8:05 PM, Andy Lutomirski <luto@kernel.org> wrote: >>> On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>>> On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski <luto@kernel.org> wrote: >>>>> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>>>>> It is used for lazy binding the first time when an external function is called. >>>>>> >>>>> >>>>> Maybe I'm just being dense, but why? What does ld.so need to do to >>>>> resolve a symbol and update the GOT that requires using extended >>>>> state? >>>> >>>> Since the first 8 vector registers are used to pass function parameters >>>> and ld.so uses vector registers, _dl_runtime_resolve needs to preserve >>>> the first 8 vector registers when transferring control to ld.so. >>>> >>> >>> Wouldn't it be faster and more future-proof to recompile the relevant >>> parts of ld.so to avoid using extended state? >>> >> >> Are you suggesting not to use vector in ld.so? > > Yes, exactly. > >> We used to do that >> several years ago, which leads to some subtle bugs, like >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=15128 > > I don't think x86_64 has the issue that ARM has there. The Linux > kernel, for example, has always been compiled to not use vector or > floating point registers on x86 (32 and 64), and it works fine. Linux > doesn't save extended regs on kernel entry and it doesn't restore them > on exit. > > I would suggest that ld.so be compiled without use of vector > registers, that the normal lazy binding path not try to save any extra > regs, and that ifuncs be called through a thunk that saves whatever > registers need saving, possibly just using XSAVEOPT. After all, ifunc > is used for only a tiny fraction of symbols.
x86-64 was the only target which used FOREIGN_CALL macros in ld.so, FOREIGN_CALL macros were the cause of race condition in ld.so:
https://sourceware.org/bugzilla/show_bug.cgi?id=11214
Not to save and restore the first 8 vector registers means that FOREIGN_CALL macros have to be used. We don't want to do that on x86-64.
-- H.J.
| |