Re: [Qemu-devel] [COMMIT 5efa9d5] Convert block infrastructure to use new module init functionality

[Andreas Färber]

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