On Thu, Feb 17, 2022 at 04:02:16PM +0100, Serge Guelton wrote: > On Thu, Feb 17, 2022 at 12:40:40PM +0100, Paolo Bonzini wrote: > > On 2/17/22 10:28, Stefan Hajnoczi wrote: > > >>But going against ABI and toolchain in this way is really no long-term > > >>solution. You need to switch to stackless co-routines, or we need to > > >>provide proper ABI-level support for this. Today it's the thread > > >>pointer, tomorrow it's the shadow stack pointer, and the day after that, > > >>it's the SafeStack pointer. And further down the road, it's some thread > > >>state for garbage collection support. Or something like that. > > > > > >Yes, understood :(. This does feel like solving an undefined behavior > > >problem by adding more undefined behavior on top! > > > > Yes, this is the kind of thing that I generally despise when I see > > other programs do it... it's easy to dig ourselves in the same > > hole. > > > > >I took a quick look at C++20 coroutines since they are available in > > >compilers but the primitives look hard to use even from C++, let alone > > >from C. > > > > They're C++ only in GCC, too. I really think that QEMU should be > > compilable in C++, but I'm not sure how easy a sell it is. > > It's perfectly fine to have one compilation unit written in C++ with a few > symbol in `extern "C"`. No need to touch the other part of the project. >
I don't think that's possible in this case because the coroutine functions are spread throughout the codebase. All coroutine functions need to be in C++ source units so the compiler can transform them and emit code callable as a coroutine. Stefan
signature.asc
Description: PGP signature
