potential AArch64 ABI bug wrt handling of 128-bit bit-fields

Bug #1881552 reported by Philippe Mathieu-Daudé
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

After upgrading to Ubuntu 20.04 LTS, GCC 9.3 displays a lot of notes:

hw/block/pflash_cfi01.c: In function ‘pflash_mem_read_with_attrs’:
hw/block/pflash_cfi01.c:663:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  663 | static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value,
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
hw/block/pflash_cfi01.c: In function ‘pflash_mem_write_with_attrs’:
hw/block/pflash_cfi01.c:677:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  677 | static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value,
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_mem_valid’:
hw/nvram/fw_cfg.c:475:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  475 | static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr,
      | ^~~~~~~~~~~~~~~~~~~~
hw/nvram/fw_cfg.c: In function ‘fw_cfg_data_mem_valid’:
hw/nvram/fw_cfg.c:483:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  483 | static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr,
      | ^~~~~~~~~~~~~~~~~~~~~
hw/nvram/fw_cfg.c: In function ‘fw_cfg_ctl_mem_valid’:
hw/nvram/fw_cfg.c:501:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  501 | static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr,
      | ^~~~~~~~~~~~~~~~~~~~
hw/nvram/fw_cfg.c: In function ‘fw_cfg_comb_valid’:
hw/nvram/fw_cfg.c:521:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  521 | static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
      | ^~~~~~~~~~~~~~~~~
hw/intc/arm_gic.c: In function ‘gic_do_hyp_read’:
hw/intc/arm_gic.c:1996:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
 1996 | static MemTxResult gic_do_hyp_read(void *opaque, hwaddr addr, uint64_t *data,
      | ^~~~~~~~~~~~~~~
hw/intc/arm_gic.c: In function ‘gic_thiscpu_hyp_read’:
hw/intc/arm_gic.c:1979:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
 1979 | static MemTxResult gic_thiscpu_hyp_read(void *opaque, hwaddr addr, uint64_t *data,
      | ^~~~~~~~~~~~~~~~~~~~
hw/intc/arm_gic.c: In function ‘gic_get_current_pending_irq’:
hw/intc/arm_gic.c:419:17: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1
  419 | static uint16_t gic_get_current_pending_irq(GICState *s, int cpu,
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~

This seems related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=c590597c45

  This is pretty unlikely in real code, but similar to Arm, the AArch64
  ABI has a bug with the handling of 128-bit bit-fields, where if the
  bit-field dominates the overall alignment the back-end code may end up
  passing the argument correctly. This is a regression that started in
  gcc-6 when the ABI support code was updated to support overaligned
  types. The fix is very similar in concept to the Arm fix. 128-bit
  bit-fields are fortunately extremely rare, so I'd be very surprised if
  anyone has been bitten by this.

Revision history for this message
Peter Maydell (pmaydell) wrote :

The warnings aren't a problem for QEMU because we don't expose these functions as public ABI, so the whole compile will be consistently built with the same compiler version. So we added -Wno-psabi in commit bac8d222a19f4a30d to silence the compiler here.

Changed in qemu:
status: New → Fix Committed
Thomas Huth (th-huth)
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.