On 22.04.2025 17:38, Martin Storsjö wrote:
On Sat, 12 Apr 2025, Jacek Caban wrote:
---
There's an alternative way to handle this, see:
https://github.com/llvm/llvm-project/pull/135280 It would work in
this case, but I'm not convinced it's the right approach overall.
While extending the assembler to allow setting the flag is
straightforward, handling the different relocation types would be
more problematic. That wouldn't matter for this particular case, but
having proper build system support seems more flexible in general.
Thanks, this is good discussion, and the same topic as what I
commented on patch 1/3.
For this particular function, can you give some more explanations
about why this one needs to be x86_64? Is this a function that gets
called by the system cfguard framework somehow, and always needs to be
x86_64 even on arm64ec? Compared with the scanf helper, this one is
near-trivial, so it looks like it wouldn't be too hard to make an
arm64ec native version - except for whatever special things that would
need to be implemented...
This function serves as the fallback value for
__guard_dispatch_icall_fptr, which is used by compiler-generated code to
perform indirect calls in x86_64 code. Other targets, including ARM64EC,
use __guard_check_icall_fptr instead, which allows us to assume that the
caller is x86_64 in this case. Transitions between ARM64EC and x86_64
use entry/exit thunks, which require a matching function signature to
perform the conversion. Since __guard_dispatch_icall_fptr is used with
various function signatures and is independent of them, implementing it
on ARM64EC would be tricky. On the other hand, a simple jump is easy for
a JIT to handle. This also matches the fallback provided by MSVC.
Regarding embedding x86_64 code sections in an arm64ec object file, I
kinda agree with your conclusion; it'd be quite a lot of mess to
implement that - supporting building a handful of x86_64 object files
in the mingw-w64-crt build system is less of a problem than requiring
a toolchain that can assemble both at the same time.
For this particular function, with a single jmp instruction, it could
be doable to not really support assembling generic x86_64
instructions, but just encode the literal byte sequence we want to
emit, with .byte or something like that (and set flags, somehow). But
relocations are indeed a harder problem... And doing that for the
scanf case is probably not manageable.
Yes, in this case we could just encode the opcode directly, so the only
change needed in the assembler would be to allow controlling
IMAGE_SCN_GPREL. I think this would be a relatively simple change to
COFFAsmParser::parseSectionFlags. It would be sufficient for this case
and, as mentioned in the other email, we could avoid using it for the
vsscanf case.
What I'm not sure about is whether a single use case like this is
sufficient justification for extending the assembly syntax.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
