Re: [PATCH 2/2] btf: improve -dA comments for testsuite

[Alex Coplan <alex.coplan@arm.com>]

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
>