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

["Daniel P. Berrangé" <berrange@redhat.com>]

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 :|