On 1/11/19 11:40 AM, Martin Lau wrote:
> On Fri, Jan 11, 2019 at 01:33:44PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Jan 10, 2019 at 03:09:49PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> This last one is interesting, was this done on purpose? I think one
>>> level of indirection more and we would keep the original expressiveness.
>>>
>>> @@ -8473,7 +8497,7 @@
>>> struct lruvec_stat * lruvec_stat_cpu; /* 136 8 */
>>> atomic_long_t lruvec_stat[30]; /* 144 240 */
>>> /* --- cacheline 6 boundary (384 bytes) --- */
>>> - long unsigned int lru_zone_size[5][5]; /* 384 200 */
>>> + long unsigned int lru_zone_size[25]; /* 384 200 */
>>> /* --- cacheline 9 boundary (576 bytes) was 8 bytes ago --- */
>>
>> So I see this is something inherited from CTF, that is why when I worked
>> on making these tools support multiple debugging file formats I added
>> this option:
>>
>> [acme@quaco pahole]$ pahole --flat_arrays -C mem_cgroup_per_node -F dwarf ~/git/build/v4.20-rc5+/net/ipv4/tcp.o > /tmp/dwarf
>> [acme@quaco pahole]$ pahole -C mem_cgroup_per_node -F btf ~/git/build/v4.20-rc5+/net/ipv4/tcp.o > /tmp/btf
>> [acme@quaco pahole]$ diff -u /tmp/dwarf /tmp/btf
>> [acme@quaco pahole]$
>>
>> But do we want to keep it this way?
> I think ideally we should have multi-dimensional array.
> For tracing and bpf_probe_read use case, I think the offset
> will stay the same though. Yonghong, thoughts?
Right. For bpf_probe_read, the base and the offset is what you need
to calculate the address to read the field/array_element.
But I see if we try to translate btf back to C code, the btf
translated C code is a little different from the original code....
>
> The current flatten way in BTF is to avoid the type_id
> drifting. To encode multi-dimensionall array, more than one
> extra btf_type has to be added which will cause the drift.
Briefly discussed with Martin, actually we could do this e.g.,
for "int a[5][10]"
type 1:
int type
type 2:
element_type: 1
num_elements: 10
type 3:
element_type: 2
num_elements: 5
Additional [sub]array types can be placed (emitted) after all existing
types are generated to avoid type id drift.
