Hi Iain,
On 02/06/2023 09:32, Iain Sandoe wrote:
> Hi David,
>
> > On 31 May 2023, at 07:13, Indu Bhagat via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >
> > On 5/30/23 11:27, David Faust wrote:
> >> [Changes from v1:
> >> - Fix typos.
> >> - Split unrelated change into separate commit.
> >> - Improve asm comment for enum constants, update btf-enum-1 test.
> >> - Improve asm comment for DATASEC records, update btf-datasec-2 test.]
> >> Many BTF type kinds refer to other types via index to the final types
> >> list. However, the order of the final types list is not guaranteed to
> >> remain the same for the same source program between different runs of
> >> the compiler, making it difficult to test inter-type references.
> >> This patch updates the assembler comments output when writing a
> >> given BTF record to include minimal information about the referenced
> >> type, if any. This allows for the regular expressions used in the gcc
> >> testsuite to do some basic integrity checks on inter-type references.
> >> For example, for the type
> >> unsigned int *
> >> Assembly comments like the following are written with -dA:
> >> .4byte 0 ; TYPE 2 BTF_KIND_PTR ''
> >> .4byte 0x2000000 ; btt_info: kind=2, kflag=0, vlen=0
> >> .4byte 0x1 ; btt_type: (BTF_KIND_INT 'unsigned int')
> >> Several BTF tests which can immediately be made more robust with this
> >> change are updated. It will also be useful in new tests for the upcoming
> >> btf_type_tag support.
> >> Re-tested on BPF and x86_64, no known regressions.
> >> Thanks.
> >
> > LGTM.
>
> This seems to break bootstrap on x86_64 darwin with two instances of :
>
> gcc/btfout.cc:802:32: error: format ‘%lu’ expects argument of type ‘long
> unsigned int’, but argument 4 has type ‘ctf_id_t’ {aka ‘long long unsigned
> int’} [-Werror=format=]
> 802 | "TYPE %lu BTF_KIND_%s '%s’"
>
> And another on line 970.
>
> could you suggest where the change should be?
I've pushed a fix for this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620515.html
as g:f2e60a00c7c017bd87ba9afb189cbb77d8c92925.
Thanks,
Alex
> thanks
> Iain
>
