| Message ID | 20190116041916.130523-1-aik@ozlabs.ru (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [qemu] spapr: Fix fdt warnings | expand |
On 1/16/19 3:19 PM, Alexey Kardashevskiy wrote: > because TARGET_FMT_lx is defined as "%016"PRIx64. > > This uses simple "%lx" to suppress the warning. Since it is spapr which > is always 64bit, we assume here that hwaddr is always "long". This file is not solely for kvm, i.e. ppc64 hosts. Thus this is a bad assumption and will fail for a 32-bit host. You may want to use PRIx64 and assume hwaddr == uint64_t, or also include an explicit cast to uint64_t. r~
On Wed, 16 Jan 2019, Richard Henderson wrote: > On 1/16/19 3:19 PM, Alexey Kardashevskiy wrote: >> because TARGET_FMT_lx is defined as "%016"PRIx64. >> >> This uses simple "%lx" to suppress the warning. Since it is spapr which >> is always 64bit, we assume here that hwaddr is always "long". > > This file is not solely for kvm, i.e. ppc64 hosts. Thus this > is a bad assumption and will fail for a 32-bit host. > > You may want to use PRIx64 and assume hwaddr == uint64_t, or > also include an explicit cast to uint64_t. I don't know the context of this but there's HWADDR_PRIx as well so if you want to print a hwaddr that's probably the one to use. Regards, BALATON Zoltan
On Wed, 16 Jan 2019 13:01:46 +0100 (CET) BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Wed, 16 Jan 2019, Richard Henderson wrote: > > On 1/16/19 3:19 PM, Alexey Kardashevskiy wrote: > >> because TARGET_FMT_lx is defined as "%016"PRIx64. > >> > >> This uses simple "%lx" to suppress the warning. Since it is spapr which > >> is always 64bit, we assume here that hwaddr is always "long". > > > > This file is not solely for kvm, i.e. ppc64 hosts. Thus this > > is a bad assumption and will fail for a 32-bit host. > > > > You may want to use PRIx64 and assume hwaddr == uint64_t, or > > also include an explicit cast to uint64_t. > > I don't know the context of this but there's HWADDR_PRIx as well so if you > want to print a hwaddr that's probably the one to use. > Good suggestion, "%" HWADDR_PRIx does the job. Cheers, -- Greg > Regards, > BALATON Zoltan >
On 16/01/2019 23:01, BALATON Zoltan wrote: > On Wed, 16 Jan 2019, Richard Henderson wrote: >> On 1/16/19 3:19 PM, Alexey Kardashevskiy wrote: >>> because TARGET_FMT_lx is defined as "%016"PRIx64. >>> >>> This uses simple "%lx" to suppress the warning. Since it is spapr which >>> is always 64bit, we assume here that hwaddr is always "long". >> >> This file is not solely for kvm, i.e. ppc64 hosts. Thus this >> is a bad assumption and will fail for a 32-bit host. >> >> You may want to use PRIx64 and assume hwaddr == uint64_t, or >> also include an explicit cast to uint64_t. > > I don't know the context of this but there's HWADDR_PRIx as well so if > you want to print a hwaddr that's probably the one to use. Oh, thanks! I missed that :-/ I'll repost if otherwise the idea is correct and nothing relies on leading zeroes (hi, David :) ).
Patchew URL: https://patchew.org/QEMU/20190116041916.130523-1-aik@ozlabs.ru/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14
=== TEST SCRIPT END ===
CC hw/bt/hci-csr.o
CC hw/char/ipoctal232.o
/tmp/qemu-test/src/block/sheepdog.c: In function 'find_vdi_name':
/tmp/qemu-test/src/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation]
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
---
make: *** Waiting for unfinished jobs....
In function 'acpi_table_install',
inlined from 'acpi_table_add' at /tmp/qemu-test/src/hw/acpi/core.c:296:5:
/tmp/qemu-test/src/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation]
strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/core.c:203:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation]
strncpy(ext_hdr->oem_id, hdrs->oem_id, sizeof ext_hdr->oem_id);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/core.c:207:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation]
strncpy(ext_hdr->oem_table_id, hdrs->oem_table_id,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof ext_hdr->oem_table_id);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/core.c:216:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation]
strncpy(ext_hdr->asl_compiler_id, hdrs->asl_compiler_id,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof ext_hdr->asl_compiler_id);
---
cc1: all warnings being treated as errors
make: *** [/tmp/qemu-test/src/rules.mak:69: hw/acpi/core.o] Error 1
/tmp/qemu-test/src/hw/acpi/aml-build.c: In function 'build_header':
/tmp/qemu-test/src/hw/acpi/aml-build.c:1535:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation]
strncpy((char *)h->oem_id, oem_id, sizeof h->oem_id);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/aml-build.c:1541:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation]
strncpy((char *)h->oem_table_id, oem_table_id, sizeof(h->oem_table_id));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The full log is available at
http://patchew.org/logs/20190116041916.130523-1-aik@ozlabs.ru/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 83081de..37cdadb 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -375,7 +375,7 @@ static int spapr_populate_memory_node(void *fdt, int nodeid, hwaddr start, mem_reg_property[0] = cpu_to_be64(start); mem_reg_property[1] = cpu_to_be64(size); - sprintf(mem_name, "memory@" TARGET_FMT_lx, start); + sprintf(mem_name, "memory@%lx", start); off = fdt_add_subnode(fdt, 0, mem_name); _FDT(off); _FDT((fdt_setprop_string(fdt, off, "device_type", "memory")));
The FDT blob which the spapr machine renders at reset time produces warnings like this: my-181211-154309.dts: Warning (unit_address_format): Node /memory@0000000080000000 unit name should not have leading 0s my-181211-154309.dts: Warning (unit_address_format): Node /memory@0000000040000000 unit name should not have leading 0s my-181211-154309.dts: Warning (unit_address_format): Node /memory@0000000020000000 unit name should not have leading 0s my-181211-154309.dts: Warning (unit_address_format): Node /memory@0000000010000000 unit name should not have leading 0s my-181211-154309.dts: Warning (unit_address_format): Node /memory@0000000000000000 unit name should not have leading 0s because TARGET_FMT_lx is defined as "%016"PRIx64. This uses simple "%lx" to suppress the warning. Since it is spapr which is always 64bit, we assume here that hwaddr is always "long". Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- hw/ppc/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)