qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore


From: Daniel P . Berrangé
Subject: Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
Date: Tue, 18 Aug 2020 13:15:21 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

On Wed, Aug 12, 2020 at 11:46:21AM -0400, Cole Robinson wrote:
> On 7/29/20 8:50 AM, Stefan Hajnoczi wrote:
> > On Thu, Jul 16, 2020 at 05:10:26PM -0400, Cole Robinson wrote:
> >> I'm trying to build qemu 5.1.0-rc0 in Fedora. I'm hitting some issues.
> > 
> > For anyone else reading this email thread, this was fixed in QEMU
> > 5.1.0-rc1:
> > 
> >   commit d97df4b84bc42613cf9a03619de453ebd0be30b7
> >   Author: Gerd Hoffmann <kraxel@redhat.com>
> >   Date:   Mon Jul 20 12:03:50 2020 +0200
> > 
> >       qxl: fix modular builds with dtrace
> > 
> 
> FWIW I'm still hitting issues with qemu-5.1.0 GA but maybe it's
> unrelated to that specific fix. Issues reproduce on fedora 33+, not
> fedora 32.

Gerd's fix here was to remove the reference to the
conditional trace_event_get_state_backends()  checks.

This avoids referencing the systemtap  semaphore symbol.

This works..... with systemtap 4.3  or earlier.

In systemtap 4.4 they attempted to support LTO, by changing
the _SDT_PROBE macro so that it *always* references the
semaphore symbol as a hint for LTO.

This broke QEMU again.

While this is obviously a regression in behaviour in systemtap,
I think its possible to argue that QEMU's use of probes is
itself broken.

We have tracepoints in the qxl.so module, but the probes
are all linked into the qemu-system-x86_64 binary, and
not exported for use by the modules.  AFAICT, we've merely
been lucky not to hit this previously, as none of the
modules we had upto now used trace_event_get_state_backends()
checks. Any such use would always have been broken with all
systemtap versions.

IOW, new systemtap 4.4 is exposing a long standing design
flaw in QEMU's probe.

I'm gong to ask the systemtap maintainers for an opinion on
this behaviour change none the less.


If systemtap won't change, then to fix this, for any foo.c
that will be in a module, we need a separate 'foo.trace'
file that generates a .o that is directly linked to the
foo.so, not the qemu-system-x86_64 binary.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]