Re: [Qemu-devel] qemu-2007-10-24 build error

[Thiemo Seufer]

Edgar E. Iglesias wrote:
> On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote:
> > On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?????????) wrote:
> > > 
> > > gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o
> > > console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
> > > block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o
> > > block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
> > > block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o
> > > usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o
> > > eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o
> > > etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o
> > > slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o
> > > slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o
> > > slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o
> > > slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o
> > > libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil 
> > > libqemu.a(helper.o): In function `do_interrupt': 
> > > /usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined
> > > reference to `__builtin_clz' 
> > > libqemu.a(translate-op.o): In function `dyngen_code': 
> > > /home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to
> > > `__builtin_clz' 
> > > libqemu.a(op.o): In function `op_lz_T0_T1': 
> > > /usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined
> > > reference to `__builtin_clz' 
> > > collect2: ld returned 1 exit status 
> > 
> > It does not seem to be a good idea, imho, to use gcc builtins directly
> > from micro-ops. But your compiler should implement __builtin_clz. As far
> 
> Hi,
> 
> I submitted a patch that at compile-time fallbacks to clz code without 
> builtins. Do you see any additional issues with using the builtins?
> 
> I think the speed-up with GCC ports implementing fast builtin variants of 
> operations like clz would be significant enough to justify their use but if 
> there is disagreement I'll send in a new patch removing the builtin_clz 
> alltogether.

If the builtin ends up calling into libgcc (this can happen depending
on the host / host compiler), then the dynamic code generation breaks.

It is safer not to force the compiler to use builtins.


Thiemo