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
