[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFULd4YUD_7x5=j1MBB9mcS6rRm9zdmZ33SyjaTArScLVMv2KA@mail.gmail.com>
Date: Fri, 13 Oct 2023 00:44:32 +0200
From: Uros Bizjak <ubizjak@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Dave Hansen <dave.hansen@...el.com>, x86@...nel.org,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v2 0/4] Introduce %rip-relative addressing to PER_CPU_VAR macro
On Thu, Oct 12, 2023 at 11:22 PM H. Peter Anvin <hpa@...or.com> wrote:
>
> On 10/12/23 14:17, Uros Bizjak wrote:
> >>
> >> Are you PIC-adjusting the percpu variables as well?
> >
> > After this patch (and after fixing percpu_stable_op to use "a" operand
> > modifier on GCC), the only *one* remaining absolute reference to
> > percpu variable remain in xen-head.S, where:
> >
> > movq $INIT_PER_CPU_VAR(fixed_percpu_data),%rax
> >
> > should be changed to use leaq.
> >
> > All others should then be (%rip)-relative.
> >
>
> I mean, the symbols themselves are relative, not absolute?
The reference to the symbol is relative to the segment register, but
absolute to the location of the instruction. If the executable changes
location, then instruction moves around and reference is not valid
anymore. (%rip)-relative reference compensate for changed location of
the instruction.
Uros.
Powered by blists - more mailing lists