On Fri, Jun 09, 2023 at 12:57:46AM +0100, Andrew Cooper wrote:
> On 09/06/2023 12:34 am, Yunhong Jiang wrote:
> > On Tue, May 30, 2023 at 12:46:22PM +0200, Thomas Gleixner wrote:
> >> The stack locking and stack assignment macro LOAD_REALMODE_ESP fails to
> >> work when invoked from the 64bit trampoline entry point:
> >>
> >> trampoline_start64
> >> trampoline_compat
> >> LOAD_REALMODE_ESP <- lock
> > One possibly dumb question and hope get some hints.
>
> There's a phrase. "The only dumb question is the one not asked".
>
> If you have this question, there's an excellent chance that someone else
> reading this thread has the same question.
>
> > The LOAD_REALMODE_ESP is
> > defined under .code16 directive and will be used by 32-bit mode caller
> > also. Is
> > it ok because the instructions there will be same for both 16-bit and
> > 32-bit? I
> > checked
> > https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_16.html#SEC205
> > and
> > don't find much information there.
>
> The position of the LOAD_REALMODE_ESP .macro itself doesn't matter.
> It's just some text which gets pasted elsewhere. Imagine it just the
> same as running the C preprocessor on a file before compiling it.
>
> As you note, some expansions of the macro are in .code16, and some are
> not. This does result in different bytes being emitted. The default
> operands size flips between .code16 and .code32, so there will be some
> 0x66 prefixes in one mode, and not in others.
>
> The important point is the l suffix on btsl, which forces it to be long
> (32bit) irrespective of the default operand size.
>
> So yes, it will work, but that's because gas is handling the differing
> encodings automatically based on the default operand size where the
> LOAD_REALMODE_ESP gets expanded.
>
> Hope this helps,
Thank you for the explaination, it's quite clear now.
>
> ~Andrew
