While GPIO functionality is not used by user-mode emulation, it is conceptually part of qdev - GPIO pins are included in DeviceState independent of whether this is system or user-mode emulation.
For the Rust bindings, having GPIO functionality in system_ss causes a problem because, for simplicity, all methods of DeviceState are included in the Rust hwcore crate. On Windows, rustc is not able to do dead code elimination as well as on other OSes and this causes an undefined symbol error, because gpio.c is not linked into the rust/hw/core/rust-hwcore-rs-integration test binary. To fix it, move gpio.c out of system_ss and into libhwcore. Alternatively, it would be possible to define some DeviceState methods also in the system crate, using for example a separate trace SystemDeviceMethods. For now, keep all the methods in one crate and link 200 unused lines of code into user-mode emulators. Signed-off-by: Paolo Bonzini <[email protected]> --- hw/core/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/core/meson.build b/hw/core/meson.build index b5a545a0edd..8a96567de8f 100644 --- a/hw/core/meson.build +++ b/hw/core/meson.build @@ -1,6 +1,7 @@ # core qdev-related obj files, also used by *-user and unit tests hwcore_ss.add(files( 'bus.c', + 'gpio.c', 'qdev-properties.c', 'qdev.c', 'resetcontainer.c', @@ -29,7 +30,6 @@ system_ss.add(when: 'CONFIG_EIF', if_true: [files('eif.c'), zlib, libcbor, gnutl system_ss.add(files( 'cpu-system.c', 'fw-path-provider.c', - 'gpio.c', 'hotplug.c', 'loader.c', 'machine-hmp-cmds.c', -- 2.52.0
