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...
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.
So out of these alternatives, I guess the best alternative is to allow building individual files as x86_64 here, like you suggest. That can be done either like this, or some other way (to support a potential GCC case) in the future, but the concept of building x86_64 object files probably is something we need to commit to.
It'd still be good with a bit of motivation on why this one needs to be x86_64.
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
