On Tue, Apr 19, 2022 at 01:32:42PM +0200, Florian Weimer wrote:
> * Stefan Hajnoczi:
>
> > On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote:
> >> > 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++,
So, this was my primary objection during the standardization of coroutines
for C++20. Red Hat's vote was consistently against adding the feature
without library support, but here we are.
Lewis Baker (formerly at Facebook) has led most of the work since on
defining what that library support might l
* Stefan Hajnoczi:
> On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote:
>> > 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.
>>
>> Could you go into details what makes them ha
On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote:
> > 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.
>
> Could you go into details what makes them hard to use? Is it because
>
* Stefan Hajnoczi:
>> 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
On 2/17/22 16:02, Serge Guelton wrote:
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 ea
> 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.
Same story here :-/
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
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 thi
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,
On Wed, Feb 16, 2022 at 09:40:34PM +0100, Florian Weimer wrote:
> * Stefan Hajnoczi:
>
> > On Wed, 16 Feb 2022 at 18:14, Florian Weimer wrote:
> >>
> >> * Stefan Hajnoczi:
> >>
> >> > I've been trying to make the inline asm that gets the address of a TLS
> >> > variable for QEMU coroutines pass Q
On Wed, Feb 16, 2022 at 09:46:02PM +0100, Florian Weimer wrote:
> * Stefan Hajnoczi:
>
> > I'm basically asking whether the &tls_var input operand is treated as
> > volatile and part of the inline assembly or whether it's just regular
> > C code that the compiler may optimize with the surrounding
On 2/16/22 18:46, Stefan Hajnoczi wrote:
However, I wonder if the compiler might reuse a register that already
contains the address. Then we'd have the coroutine problem again when
qemu_coroutine_yield() is called between the earlier address calculation
and the asm volatile statement.
Yes, the
* Stefan Hajnoczi:
> I'm basically asking whether the &tls_var input operand is treated as
> volatile and part of the inline assembly or whether it's just regular
> C code that the compiler may optimize with the surrounding function?
&tls_var is evaluated outside of the inline assembly, any compi
* Stefan Hajnoczi:
> On Wed, 16 Feb 2022 at 18:14, Florian Weimer wrote:
>>
>> * Stefan Hajnoczi:
>>
>> > I've been trying to make the inline asm that gets the address of a TLS
>> > variable for QEMU coroutines pass QEMU's GitLab CI.
>> > https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/
On Wed, 16 Feb 2022 at 20:28, Stefan Hajnoczi wrote:
>
> On Wed, 16 Feb 2022 at 18:14, Florian Weimer wrote:
> >
> > * Stefan Hajnoczi:
> >
> > > I've been trying to make the inline asm that gets the address of a TLS
> > > variable for QEMU coroutines pass QEMU's GitLab CI.
> > > https://gitlab.c
On Wed, 16 Feb 2022 at 18:14, Florian Weimer wrote:
>
> * Stefan Hajnoczi:
>
> > I've been trying to make the inline asm that gets the address of a TLS
> > variable for QEMU coroutines pass QEMU's GitLab CI.
> > https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/include/qemu/coroutine-tls.h
* Stefan Hajnoczi:
> I've been trying to make the inline asm that gets the address of a TLS
> variable for QEMU coroutines pass QEMU's GitLab CI.
> https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/include/qemu/coroutine-tls.h#L89
>
> The code isn't -fPIC-friendly (R_X86_64_TPOFF32 relocat
Hi,
I've been trying to make the inline asm that gets the address of a TLS
variable for QEMU coroutines pass QEMU's GitLab CI.
https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/include/qemu/coroutine-tls.h#L89
The code isn't -fPIC-friendly (R_X86_64_TPOFF32 relocations aren't
allowed in -f
19 matches
Mail list logo
