[Lldb-commits] [PATCH] D129455: [lldb] Reduce the stack alignment requirements for the Windows x86_64 ABI

Tue Jul 12 00:38:52 PDT 2022

labath added a comment.

In D129455#3642015 <https://reviews.llvm.org/D129455#3642015>, @mstorsjo wrote:

> In D129455#3641967 <https://reviews.llvm.org/D129455#3641967>, @labath wrote:
>
>> You say that the issue is the lack of symtab in the "msvc" mode. What makes this test work then?
>
> When invoked via the `%build` python script (lldb/test/Shell/helper/build.py), clang is invoked with extra options (`/Z7`) that generate codeview debug info, and then later the linker is invoked with extra options (`/DEBUG:FULL` and `'/PDB:' + self._pdb_file_name())`) to write that codeview debug info into a separate standalone PDB file.

Ok. So I take it this means the resulting PDB will contain debug info describing the .s file (the location of `call_func`)? Similar to how clang w/dwarf will emit a DW_TAG_label when compiling an .s file with `-g` (?)

>> Do some of the assembler directives (`.def`?) produce some sort of debug info entries?
>
> Those just set the symbol type to "function" - it could be omitted from this test for clarity.
>
>> What determines the modes that clang is operating in? Is it the default target triple?
>
> Exactly.

Got it. Thanks.

> Additionally, there's a couple more tooling differences that makes things a bit more complicated:
>
> In the MSVC ecosystem, you normally would execute cl.exe (the MSVC compiler) or clang-cl (the cl.exe compatible clang frontend) - which has got an option syntax that is distinct and mostly incompatible from the gcc-compatible normal `clang` interface.
>
> Despite this, you can also build code in MSVC mode with the regular gcc-compatible clang interface (either by passing e.g. `--target=x86_64-windows-msvc` or if such a triple is the deafult target triple). You can do most things in this setup too, but some MSVC-isms are tricky to achieve. This is what the `%clang_host` lit test macro does. Regular compiling, e.g. `%clang_host input.c -o executable -luser32` works fine for both MSVC and mingw mode.
>
> In the MSVC ecosystem, you very rarely use the compiler driver to run linking - you'd normally execute `link.exe` or `lld-link` directly. If linking via the gcc-compatible clang interface, options passed to the linked with `-Wl,` need to be link.exe/lld-link options, which a unix-style linker obviously doesn't recognize.

Ok, makes sense. If some test requires a specific "msvc-ism", then I think that test can stay windows-only, and invoke clang-cl (or whatever) directly. What I'd like to figure out is how to write simple tests that don't depend on any architecture specifics in an cross-platform manner. Or (since we already kind of have that), I guess I should say, expand the scope of what can be done that way.

> A bunch of tests might be doable crossplatform that way, but any tests that involve assembly might be tricky. On i386, arm and aarch64, Windows has got mostly the same calling conventions as other OSes, but on x86_64, it's radically different - arguments are passed in different registers than on x86_64 unix. Additionally, the caller is required to allocate shadow space on the stack for all arguments passed in registers (the extra `subq $32, %rsp`) so that the callee can dump them there if wanted. And finally, this particular testcase generates SEH unwind instructions with the `.seh_*` directives. (I didn't test whether the testcase would work without the SEH unwind instructions or not - I made it to look mostly like what a regular Windows function would look like.)

Yes, asm is tricky even without cross-platform considerations. I don't imagine we will be having many of these tests, but some things are hard to test differently. It's either this or core files, and both options have a lot of disadvantages. The good thing about asm and calling conventions is that, as long as you're staying with the asm code, the exact calling convention does not really matter. And a lot of these asm tests are for situations where the code uses some kind of nonstandard calling convention (yes, the spec says you should allocate shadow space, but it also says you should align the stack, yet here we are..)

I'm also wondering if we could not use inline asm (either in `__attribute__((naked))` functions, or as top-level asm blocks) instead of actual asm files. I think that could insulate us from some of the target asm specifics, and (in the first case) take care of the function declaration boilerplate.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129455/new/

https://reviews.llvm.org/D129455