Re: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set

[Mark Cave-Ayland]

On 03/05/2022 15:06, Fabiano Rosas wrote:

> Murilo Opsfelder Araújo <muriloo@linux.ibm.com> writes:
>
> > $ cat > configs/devices/rh-virtio.mak <<"EOF"
> > CONFIG_VIRTIO=y
> > CONFIG_VIRTIO_BALLOON=y
> > CONFIG_VIRTIO_BLK=y
> > CONFIG_VIRTIO_GPU=y
> > CONFIG_VIRTIO_INPUT=y
> > CONFIG_VIRTIO_INPUT_HOST=y
> > CONFIG_VIRTIO_NET=y
> > CONFIG_VIRTIO_RNG=y
> > CONFIG_VIRTIO_SCSI=y
> > CONFIG_VIRTIO_SERIAL=y
> > EOF
> >
> > $ cat > configs/devices/ppc64-softmmu/ppc64-rh-devices.mak <<"EOF"
> > include ../rh-virtio.mak
> > CONFIG_DIMM=y
> > CONFIG_MEM_DEVICE=y
> > CONFIG_NVDIMM=y
> > CONFIG_PCI=y
> > CONFIG_PCI_DEVICES=y
> > CONFIG_PCI_TESTDEV=y
> > CONFIG_PCI_EXPRESS=y
> > CONFIG_PSERIES=y
> > CONFIG_SCSI=y
> > CONFIG_SPAPR_VSCSI=y
> > CONFIG_TEST_DEVICES=y
> > CONFIG_USB=y
> > CONFIG_USB_OHCI=y
> > CONFIG_USB_OHCI_PCI=y
> > CONFIG_USB_SMARTCARD=y
> > CONFIG_USB_STORAGE_CORE=y
> > CONFIG_USB_STORAGE_CLASSIC=y
> > CONFIG_USB_XHCI=y
> > CONFIG_USB_XHCI_NEC=y
> > CONFIG_USB_XHCI_PCI=y
> > CONFIG_VFIO=y
> > CONFIG_VFIO_PCI=y
> > CONFIG_VGA=y
> > CONFIG_VGA_PCI=y
> > CONFIG_VHOST_USER=y
> > CONFIG_VIRTIO_PCI=y
> > CONFIG_VIRTIO_VGA=y
> > CONFIG_WDT_IB6300ESB=y
> > CONFIG_XICS=y
> > CONFIG_XIVE=y
> > CONFIG_TPM=y
> > CONFIG_TPM_SPAPR=y
> > CONFIG_TPM_EMULATOR=y
> > EOF
> >
> > $ mkdir build
> > $ cd build
>
> <snip>
>
> > $ ../configure --without-default-devices --with-devices-ppc64=ppc64-rh-devices 
> > --target-list=ppc64-softmmu
> > $ make -j
> > ...
> > /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/monitor_misc.c.o:(.data.rel+0x3228): 
> > undefined reference to `hmp_info_via'
> > collect2: error: ld returned 1 exit status
> >
> > Since TARGET_PPC is defined when building target ppc64-softmmu, the 
> > hmp_info_via will be referenced when processing the hmp-commands-info.hx.
> > However, hmp_info_via implementation resides on hw/misc/mos6522.c, which is 
> > built only if CONFIG_MOS6522 is defined, as per hw/misc/meson.build.
>
> I think this particular problem you hit is due to the 64 bit devices
> file including 32 bit as well:
>
> $ cat configs/devices/ppc64-softmmu/default.mak
> # Default configuration for ppc64-softmmu
>
> # Include all 32-bit boards
> include ../ppc-softmmu/default.mak <----- here
>
> # For PowerNV
> CONFIG_POWERNV=y
>
> # For pSeries
> CONFIG_PSERIES=y
> ---
>
> So ppc64-softmmu doesn't quite do what it says on the tin. I think in
> the long run we need to revisit the conversation about whether to keep
> the 32 & 64 bit builds separate. It is misleading that you're explicitly
> excluding ppc-softmmu from the `--target-list`, but a some 32 bit stuff
> still comes along implicitly.

Unfortunately for historical reasons it isn't quite that simple: the mac99 machine in 
hw/ppc/mac_newworld.c is both a 32-bit and a 64-bit machine, but with a different PCI 
host bridge and a 970 CPU if run from qemu-system-ppc64. Unfortunately it pre-dates 
my time working on QEMU's PPC Mac machines but I believe it was (is?) capable of 
booting Linux, even though I doubt it accurately represents a real machine.

> > If hmp_info_via is generic enough and not device-specific, it could be moved 
> > out of mos6522.c to somewhere else.
>
> Perhaps it would be easier to just have a stub for the 64 bits build? Do
> HMP commands get in any way enabled/disabled depending on the emulated
> hw that is available? It might be ok to have a hmp_info_via that is a
> noop in 64bit.

I've provided a pointer back to the original thread in my previous reply which I hope 
will give some background here.


ATB,

Mark.