[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFULd4YPVcWL6_bo2T4O=a6ed9hTOakp2m1_XBF3w-uWhyd4dQ@mail.gmail.com>
Date: Mon, 6 Nov 2023 15:25:43 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: x86@...nel.org, linux-pm@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/acpi: Use %rip-relative addressing in wakeup_64.S
On Mon, Nov 6, 2023 at 3:14 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Fri, Nov 3, 2023 at 11:49 AM Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > Instruction with %rip-relative address operand is one byte shorter than
> > its absolute address counterpart and is also compatible with position
> > independent executable (-fpie) build.
> >
> > No functional changes intended.
>
> I'm wondering what's the exact motivation for making this change.
Mainly to be consistent with what the compiler emits by default when a
symbol is accessed. As said in the commit message, the %rip-relative
access is also one byte shorter, and results in a position independent
code.
> Any urgent need for it doesn't seem to be there.
True. It's mostly a nice-to-have change.
Thanks,
Uros.
> > Cc: "Rafael J. Wysocki" <rafael@...nel.org>
> > Cc: Len Brown <len.brown@...el.com>
> > Cc: Pavel Machek <pavel@....cz>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > Cc: Borislav Petkov <bp@...en8.de>
> > Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> > Cc: "H. Peter Anvin" <hpa@...or.com>
> > Signed-off-by: Uros Bizjak <ubizjak@...il.com>
> > ---
> > arch/x86/kernel/acpi/wakeup_64.S | 24 ++++++++++++------------
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> > index d5d8a352eafa..94ff83f3d3fe 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -17,7 +17,7 @@
> > * Hooray, we are in Long 64-bit mode (but still running in low memory)
> > */
> > SYM_FUNC_START(wakeup_long64)
> > - movq saved_magic, %rax
> > + movq saved_magic(%rip), %rax
> > movq $0x123456789abcdef0, %rdx
> > cmpq %rdx, %rax
> > je 2f
> > @@ -33,14 +33,14 @@ SYM_FUNC_START(wakeup_long64)
> > movw %ax, %es
> > movw %ax, %fs
> > movw %ax, %gs
> > - movq saved_rsp, %rsp
> > + movq saved_rsp(%rip), %rsp
> >
> > - movq saved_rbx, %rbx
> > - movq saved_rdi, %rdi
> > - movq saved_rsi, %rsi
> > - movq saved_rbp, %rbp
> > + movq saved_rbx(%rip), %rbx
> > + movq saved_rdi(%rip), %rdi
> > + movq saved_rsi(%rip), %rsi
> > + movq saved_rbp(%rip), %rbp
> >
> > - movq saved_rip, %rax
> > + movq saved_rip(%rip), %rax
> > ANNOTATE_RETPOLINE_SAFE
> > jmp *%rax
> > SYM_FUNC_END(wakeup_long64)
> > @@ -72,11 +72,11 @@ SYM_FUNC_START(do_suspend_lowlevel)
> >
> > movq $.Lresume_point, saved_rip(%rip)
> >
> > - movq %rsp, saved_rsp
> > - movq %rbp, saved_rbp
> > - movq %rbx, saved_rbx
> > - movq %rdi, saved_rdi
> > - movq %rsi, saved_rsi
> > + movq %rsp, saved_rsp(%rip)
> > + movq %rbp, saved_rbp(%rip)
> > + movq %rbx, saved_rbx(%rip)
> > + movq %rdi, saved_rdi(%rip)
> > + movq %rsi, saved_rsi(%rip)
> >
> > addq $8, %rsp
> > movl $3, %edi
> > --
Powered by blists - more mailing lists