All of lore.kernel.org
 help / color / mirror / Atom feed
* hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
@ 2020-07-16 21:10 Cole Robinson
  2020-07-29 12:50 ` Stefan Hajnoczi
  0 siblings, 1 reply; 10+ messages in thread
From: Cole Robinson @ 2020-07-16 21:10 UTC (permalink / raw)
  To: qemu-devel, Gerd Hoffmann

Hi Gerd,

I'm trying to build qemu 5.1.0-rc0 in Fedora. I'm hitting some issues.

Using this configure line:

./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc
--localstatedir=/var --libexecdir=/usr/libexec
--interp-prefix=/usr/qemu-%M --with-pkgversion=qemu-5.1.0-0.1.rc0.fc33
'--extra-ldflags=-Wl,--build-id -Wl,-z,relro -Wl,-z,now'
'--extra-cflags=-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
--enable-trace-backend=dtrace --audio-drv-list=pa,sdl,alsa,oss
--enable-kvm --target-list=x86_64-softmmu --enable-pie --enable-modules
--enable-spice

Build and then run:

$ ./x86_64-softmmu/qemu-system-x86_64 -device \? | grep qxl
Failed to open module:
/home/crobinso/src/qemu/x86_64-softmmu/../hw-display-qxl.so: undefined
symbol: qemu_qxl_io_log_semaphore


That error breaks iotests 127:

--- /home/crobinso/src/qemu/tests/qemu-iotests/127.out	2020-07-15
04:00:10.589138586 -0400
+++ /home/crobinso/src/qemu/tests/qemu-iotests/127.out.bad	2020-07-16
16:44:37.717248172 -0400
@@ -1,4 +1,5 @@
 QA output created by 127
+Failed to open module:
/home/crobinso/src/qemu/x86_64-softmmu/../hw-display-qxl.so: undefined
symbol: qemu_qxl_io_log_semaphore
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=65536
 Formatting 'TEST_DIR/t.IMGFMT.overlay0', fmt=IMGFMT size=65536
backing_file=TEST_DIR/t.IMGFMT backing_fmt=IMGFMT
 Formatting 'TEST_DIR/t.IMGFMT.overlay1', fmt=IMGFMT size=65536
backing_file=TEST_DIR/t.IMGFMT backing_fmt=IMGFMT


Doing a build with every target and running 'make check' will show
undefined symbol errors for other targets with hw-display-qxl too. Most
reference the qxl_io_log call but some are like:

Failed to open module:
/home/crobinso/src/qemu/microblaze-softmmu/../hw-display-qxl.so:
undefined symbol: vga_ioport_read


Also as a side note though I think it's pre-existing: running the test
suite with --enable-modules while there are host installed modules is
very noisy with lots of repetitive warnings like:

Failed to initialize module: /usr/lib64/qemu/audio-oss.so
Note: only modules from the same build can be loaded.
Failed to initialize module: /usr/lib64/qemu/audio-pa.so
Note: only modules from the same build can be loaded.
Failed to initialize module: /usr/lib64/qemu/audio-sdl.so
Note: only modules from the same build can be loaded.
Failed to initialize module: /usr/lib64/qemu/ui-curses.so
Note: only modules from the same build can be loaded.
Failed to initialize module: /usr/lib64/qemu/ui-gtk.so
Note: only modules from the same build can be loaded.

It would be nice if those could be avoided somehow. Maybe
QEMU_MODULE_DIR can help?

Thanks,
Cole



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-07-16 21:10 hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore Cole Robinson
@ 2020-07-29 12:50 ` Stefan Hajnoczi
  2020-08-12 15:46   ` Cole Robinson
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Hajnoczi @ 2020-07-29 12:50 UTC (permalink / raw)
  To: Cole Robinson; +Cc: qemu-devel, Gerd Hoffmann

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

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

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-07-29 12:50 ` Stefan Hajnoczi
@ 2020-08-12 15:46   ` Cole Robinson
  2020-08-17  5:39     ` Gerd Hoffmann
  2020-08-18 12:15     ` Daniel P. Berrangé
  0 siblings, 2 replies; 10+ messages in thread
From: Cole Robinson @ 2020-08-12 15:46 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: qemu-devel, Gerd Hoffmann

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.

Here's a build log for 5.1.0 GA on Fedora 33 x86_64:
https://kojipkgs.fedoraproject.org//work/tasks/6937/49136937/build.log

grep for 'undefined symbol' and you'll see qemu-iotest failures, for
example:

--- /builddir/build/BUILD/qemu-5.1.0-rc3/tests/qemu-iotests/127.out
2020-08-05 16:41:09.000000000 +0000
+++
/builddir/build/BUILD/qemu-5.1.0-rc3/build-dynamic/tests/qemu-iotests/127.out.bad
2020-08-11 19:50:39.245897057 +0000
@@ -1,4 +1,5 @@
 QA output created by 127
+Failed to open module:
/builddir/build/BUILD/qemu-5.1.0-rc3/build-dynamic/x86_64-softmmu/../hw-display-qxl.so:
undefined symbol: qemu_qxl_client_monitors_config_crc_semaphore


On s390x where spice+qxl aren't compiled, we see different symbol errors
in the logs here:
https://kojipkgs.fedoraproject.org//work/tasks/6091/49136091/build.log

--- /builddir/build/BUILD/qemu-5.1.0/tests/qemu-iotests/127.out
2020-08-11 19:17:15.000000000 +0000
+++
/builddir/build/BUILD/qemu-5.1.0/build-dynamic/tests/qemu-iotests/127.out.bad
2020-08-12 12:16:20.472179636 +0000
@@ -1,4 +1,5 @@
 QA output created by 127
+Failed to open module:
/builddir/build/BUILD/qemu-5.1.0/build-dynamic/s390x-softmmu/../hw-usb-smartcard.so:
undefined symbol: ccid_card_send_apdu_to_guest

So maybe there's a more general problem. FWIW Fedora 33 started using
LTO by default, but it was disabled for the qemu package.

- Cole



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-12 15:46   ` Cole Robinson
@ 2020-08-17  5:39     ` Gerd Hoffmann
  2020-08-17 18:06       ` Cole Robinson
  2020-08-18 12:15     ` Daniel P. Berrangé
  1 sibling, 1 reply; 10+ messages in thread
From: Gerd Hoffmann @ 2020-08-17  5:39 UTC (permalink / raw)
  To: Cole Robinson; +Cc: Stefan Hajnoczi, qemu-devel

  Hi,

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

> +Failed to open module:
> /builddir/build/BUILD/qemu-5.1.0-rc3/build-dynamic/x86_64-softmmu/../hw-display-qxl.so:
> undefined symbol: qemu_qxl_client_monitors_config_crc_semaphore

> /builddir/build/BUILD/qemu-5.1.0/build-dynamic/s390x-softmmu/../hw-usb-smartcard.so:
> undefined symbol: ccid_card_send_apdu_to_guest

> So maybe there's a more general problem. FWIW Fedora 33 started using
> LTO by default, but it was disabled for the qemu package.

Hmm, the first looks like a problem.  I'm wondering why it happens on
f33 only, not f32.  LTO could explain that (optimizing away symbols used
by modules but not main qemu), but with that already turned off I have
no clue offhand.

The second is sort-of expected, this comes from s390x not supporting
usb.  I have a pending patch to silence those warnings when qemu tries
to load all available modules (for introspection, to make sure the qom
object list is complete).

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-17  5:39     ` Gerd Hoffmann
@ 2020-08-17 18:06       ` Cole Robinson
  2020-08-18  7:22         ` Gerd Hoffmann
  0 siblings, 1 reply; 10+ messages in thread
From: Cole Robinson @ 2020-08-17 18:06 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Stefan Hajnoczi, Daniel P. Berrange, qemu-devel

On 8/17/20 1:39 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> 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.
> 
>> +Failed to open module:
>> /builddir/build/BUILD/qemu-5.1.0-rc3/build-dynamic/x86_64-softmmu/../hw-display-qxl.so:
>> undefined symbol: qemu_qxl_client_monitors_config_crc_semaphore
> 
>> /builddir/build/BUILD/qemu-5.1.0/build-dynamic/s390x-softmmu/../hw-usb-smartcard.so:
>> undefined symbol: ccid_card_send_apdu_to_guest
> 
>> So maybe there's a more general problem. FWIW Fedora 33 started using
>> LTO by default, but it was disabled for the qemu package.
> 
> Hmm, the first looks like a problem.  I'm wondering why it happens on
> f33 only, not f32.  LTO could explain that (optimizing away symbols used
> by modules but not main qemu), but with that already turned off I have
> no clue offhand.
> 

I stripped down the reproducer. Dropping --enable-trace-backend=dtrace
makes things work AFAICT. This is on f33

dnf builddep -y qemu  # to get all the fedora package build deps
cd qemu.git
git checkout v5.1.0
./configure --target-list=x86_64-softmmu --disable-werror
--enable-modules --enable-trace-backend=dtrace
make
./x86_64-softmmu/qemu-system-x86_64 -vga qxl

# ./x86_64-softmmu/qemu-system-x86_64 -vga qxl
Failed to open module: /root/qemu.git/x86_64-softmmu/../ui-gtk.so:
undefined symbol: qemu_xkeymap_keymap_semaphore
Failed to open module: /root/qemu.git/x86_64-softmmu/../ui-sdl.so:
undefined symbol: qemu_sdl2_process_key_semaphore
Failed to open module:
/root/qemu.git/x86_64-softmmu/../hw-display-qxl.so: undefined symbol:
qemu_qxl_render_blit_semaphore
qemu-system-x86_64: QXL VGA not available

So nothing specific to qxl, seems all modules are busted.
I tried downgrading gcc to f32 versions, no difference. Same after
downgrading binutils. Downgrading glibc downgrades the whole distro so I
didn't attempt it

Output of this looks similar on f33 and f32:

nm {hw-display-qxl.so,x86_64-softmmu/qemu-system-x86_64} | grep
qemu_qxl_spice_destroy_surfaces_complete_semaphore

Any suggestions?

Thanks,
Cole



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-17 18:06       ` Cole Robinson
@ 2020-08-18  7:22         ` Gerd Hoffmann
  0 siblings, 0 replies; 10+ messages in thread
From: Gerd Hoffmann @ 2020-08-18  7:22 UTC (permalink / raw)
  To: Cole Robinson; +Cc: Stefan Hajnoczi, Daniel P. Berrange, qemu-devel

  Hi,

> So nothing specific to qxl, seems all modules are busted.
> I tried downgrading gcc to f32 versions, no difference. Same after
> downgrading binutils. Downgrading glibc downgrades the whole distro so I
> didn't attempt it

> Any suggestions?

Try downgrade rpm macros?

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-12 15:46   ` Cole Robinson
  2020-08-17  5:39     ` Gerd Hoffmann
@ 2020-08-18 12:15     ` Daniel P. Berrangé
  2020-08-18 12:33       ` Daniel P. Berrangé
  2020-08-20  8:29       ` Gerd Hoffmann
  1 sibling, 2 replies; 10+ messages in thread
From: Daniel P. Berrangé @ 2020-08-18 12:15 UTC (permalink / raw)
  To: Cole Robinson; +Cc: Stefan Hajnoczi, qemu-devel, Gerd Hoffmann

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-18 12:15     ` Daniel P. Berrangé
@ 2020-08-18 12:33       ` Daniel P. Berrangé
  2020-08-20  8:29       ` Gerd Hoffmann
  1 sibling, 0 replies; 10+ messages in thread
From: Daniel P. Berrangé @ 2020-08-18 12:33 UTC (permalink / raw)
  To: Cole Robinson; +Cc: Stefan Hajnoczi, qemu-devel, Gerd Hoffmann

On Tue, Aug 18, 2020 at 01:15:21PM +0100, Daniel P. Berrangé wrote:
> 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.

Reported to systemtap maintainers here:

  https://bugzilla.redhat.com/show_bug.cgi?id=1869642

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-18 12:15     ` Daniel P. Berrangé
  2020-08-18 12:33       ` Daniel P. Berrangé
@ 2020-08-20  8:29       ` Gerd Hoffmann
  2020-08-20  8:46         ` Daniel P. Berrangé
  1 sibling, 1 reply; 10+ messages in thread
From: Gerd Hoffmann @ 2020-08-20  8:29 UTC (permalink / raw)
  To: Daniel P. Berrangé; +Cc: Stefan Hajnoczi, qemu-devel, Cole Robinson

  Hi,

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

I think that is the plan anyway.

take care,
  Gerd



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore
  2020-08-20  8:29       ` Gerd Hoffmann
@ 2020-08-20  8:46         ` Daniel P. Berrangé
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel P. Berrangé @ 2020-08-20  8:46 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: Stefan Hajnoczi, qemu-devel, Cole Robinson

On Thu, Aug 20, 2020 at 10:29:43AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > 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.
> 
> I think that is the plan anyway.

It looks like we have no choice. The systemtap maintainers don't want to
change to make the semaphore symbols in the binary visible to modules.


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



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-08-20  8:47 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-16 21:10 hw-display-qxl.so: undefined symbol: qemu_qxl_io_log_semaphore Cole Robinson
2020-07-29 12:50 ` Stefan Hajnoczi
2020-08-12 15:46   ` Cole Robinson
2020-08-17  5:39     ` Gerd Hoffmann
2020-08-17 18:06       ` Cole Robinson
2020-08-18  7:22         ` Gerd Hoffmann
2020-08-18 12:15     ` Daniel P. Berrangé
2020-08-18 12:33       ` Daniel P. Berrangé
2020-08-20  8:29       ` Gerd Hoffmann
2020-08-20  8:46         ` Daniel P. Berrangé

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.