Re: Thread safety of coroutine-sigaltstack

[Laszlo Ersek <lersek@redhat.com>]

On 01/23/21 14:35, Peter Maydell wrote:
> On Sat, 23 Jan 2021 at 00:06, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 01/22/21 11:14, Peter Maydell wrote:
>>> I think (but have not checked) that that means we will build and
>>> link the object file into the user-mode binaries if you happen
>>> to build them in the same run as system-mode binaries,
>>
>> I did that, first running
>>
>>  ./configure \
>>     --enable-debug \
>>     --target-list==x86_64-softmmu,x86_64-linux-user \
>>     --with-coroutine=sigaltstack
>>
>> Then I checked the "qemu-system-x86_64" and "qemu-x86_64" binaries with
>> "nm". Only the former contains "coroutine_init":
>>
>> 00000000009725e4 t coroutine_init
>>
>> So I believe the coroutine object file(s) are not even linked into the
>> user-mode emulators. (coroutine_init() is a constructor function, so I
>> think it would be preserved otherwise, even if it had no explicit caller.)
> 
> I think the linker will only pull in a .o file from a static
> library (for us, libqemuutil.a) if there's an explicit reference
> to a real function that it needs; it won't pull it in merely because
> it has a constructor function in it. I can't offhand find an official
> docs reference for this, but here's a stack overflow question:
> https://stackoverflow.com/questions/6589772/gcc-functions-with-constructor-attribute-are-not-being-linked
> 
> You can also touch the coroutine source file and watch the
> build system rebuild the usermode binary. If you do a complete build,
> then touch util/coroutine-ucontext.c, then do 'make -C builddir qemu-arm'
> (or whatever usermode emulator you've configured) then:
>  * we build coroutine-ucontext.c into
> libqemuutil.a.p/util_coroutine-ucontext.c.o
>  * we blow away libqemuutil.a and then run 'ar' to put a lot of .o
>    files into it, including libqemuutil.a.p/util_coroutine-ucontext.c.o
>  * we do some things with scripts/undefsym.py that aren't important here
>  * we re-link qemu-arm with all its directly used objects and also with
>    libqemuutil.a
> 
> So right now we aren't actually using the coroutine functions, but
> if you did put in a call to one in code used by the usermode
> emulator then that code would only fail to compile if you
> were building the usermode emulators without either the tools
> or the system emulators.

Two thoughts (apart from the original topic):

- Should we file an LP ticket about this, perhaps? It looks moderately
risky.

- How does this case differ from the registration of types? type_init()
is a constructor function, and it generally ends up adding some
structures with function pointers (I reckon) via type_table_add(). The
main executable doesn't call into the device code directly -- only the
constructor function calls another function from the same module. The
main executable only goes through the registered type interfaces. How
does the linker know in that case to preserve the whole object?

Thanks!
Laszlo