[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [COMMIT 5efa9d5] Convert block infrastructure to use ne
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [COMMIT 5efa9d5] Convert block infrastructure to use new module init functionality |
Date: |
Sat, 13 Jun 2009 22:40:45 +0200 |
Am 31.05.2009 um 15:29 schrieb Andreas Färber:
Am 31.05.2009 um 12:15 schrieb Anthony Liguori:
Starting with this commit, qemu-system-sparc segfaults immediately;
you later fixed it in c833ab7351f2ebac46740380a81e34482e208dcc (Fix
segv when passing an unknown protocol) to no longer segfault, now
printing "qemu: could not read disk image /path/to/image".
I would assume -z,allextract isn't doing what we would like it to
do on
OpenSolaris.
It's actually using -Wl,--whole-archive (GNU ld version 2.15 on
OpenSolaris 2009.06 snv_111b).
Sorry, your assumption was actually right.
The above version string is from `ld` (/usr/gnu/bin/ld), but gcc is
configured to use /usr/ccs/bin/ld instead, the usual suspect.
Sun documents it to support both --whole-archive and -z allextract,
which explains the detection and use of --Wl,--whole-archive.
Reordering the checks, so that -Wl,-z,allextract is preferred, does
not help.
`qemu-img` correctly lists all the formats, which I thought was a
test case for the linker option.
`qemu -drive format=?` appears to better mirror the actual block
format support.
Trying to use `ld` directly for the LINK rule didn't work due to
architectural mismatches - it kept the output format as i386 despite
any -A or -b elf64-x86-64 flags I set (-m64 didn't seem to be valid).
If I manually link ../block/raw-posix.o into i386-softmmu's $
(QEMU_PROG), then instead of the original error message I get "qemu:
hardware error: Unknown device 'smbus-eeprom'" followed by a segfault.
I assume this is due to libqemuhw64.a.
With upstream qemu, the Supported formats list is empty, with ../block/
raw-posix.o linked in, it reads "host_device raw".
So it seems linking object files works while linking static libraries
does not.
Architecturally the problem appears to be that the set of objects to
link is determined in Makefile and Makefile.hw but is unknown to
Makefile.target, where the problematic linking happens.
As a workaround, I've written the respective set of $(OBJS) to a file
when linking and appending them to the LINK command. Except for two
warnings (../aio.h and ../cache-utils.o linked twice) this works fine
and makes BeOS boot up again.
Most likely someone will have a more efficient idea how to get the
list of objects to Makefile.target and how to make the list unique to
avoid warnings.
Andreas
diff --git a/Makefile b/Makefile
index 3177616..8fca061 100644
--- a/Makefile
+++ b/Makefile
@@ -229,6 +229,8 @@ curses.o: curses.c keymaps.h curses_keys.h
bt-host.o: CFLAGS += $(CONFIG_BLUEZ_CFLAGS)
libqemu_common.a: $(OBJS)
+ rm libqemu_common.mak
+ for o in $(OBJS); do echo ../$$o >> libqemu_common.mak; done
#######################################################################
# USER_OBJS is code used by qemu userspace emulation
diff --git a/Makefile.hw b/Makefile.hw
index 6accb3b..9555a86 100644
--- a/Makefile.hw
+++ b/Makefile.hw
@@ -33,6 +33,8 @@ all: $(HWLIB)
@true
$(HWLIB): $(OBJS)
+ -rm -f $(HWLIB).list
+ for o in $(OBJS); do echo ../libhw64/$$o >> $(HWLIB).list; done
clean:
rm -f *.o *.d *.a *~
diff --git a/Makefile.target b/Makefile.target
index 27de4b9..8b86b62 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -735,9 +735,9 @@ vl.o: qemu-options.h
monitor.o: qemu-monitor.h
$(QEMU_PROG): LIBS += $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) $
(BRLAPI_LIBS) $(VDE_LIBS) $(CURL_LIBS)
-$(QEMU_PROG): ARLIBS=../libqemu_common.a libqemu.a $(HWLIB)
+$(QEMU_PROG): ARLIBS=libqemu.a
$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(HWLIB)
- $(call LINK,$(OBJS))
+ $(call LINK,$(OBJS) `cat ../libqemu_common.mak` `cat $(HWLIB).list`)
endif # !CONFIG_USER_ONLY
wholearchive-workaround.diff
Description: Binary data
- Re: [Qemu-devel] [COMMIT 5efa9d5] Convert block infrastructure to use new module init functionality,
Andreas Färber <=