Hello,

The flexible arrays are dynamically allocated with different size.  So checking
with the original type size won't match and cannot find the type if the offset
is bigger than the size.  This patch series detects those flex-arrays and allows
accesses beyong the original size.

I'm not sure what's the best way to add test codes for data type profiling as it
seems we need to add a lot more workloads for different cases.  Probably we may
want to split the workloads as separate binaries.

v5 changes)

 * add a cleanup patch
 * add is_union and is_flex_array fields to find member correctly

v4: https://lore.kernel.org/r/20260916061926.2224222-1-namhyung@kernel.org/

 * update last member even if the offset is same
 * handle type qualifiers in die_has_flex_array()
 * add zero-length array members as flexible arrays
 * check return value of strbuf_init() for type name

v3: https://lore.kernel.org/r/20260915064035.1970175-1-namhyung@kernel.org

 * patch 1 was merged!
 * check if last member is found
 * check member location when finding flex-array
 * ensure member typename is initiailized
 * fix a bug to pass a wrong type in check_variable()
 * fix a typo in a comment

v2: https://lore.kernel.org/r/20260914064535.1671939-1-namhyung@kernel.org

 * fix missing index increment in the histogram
 * support flex array in union types
 * add recursion check in die_has_flex_array()
 * check negative index arrays properly
 * avoid divide-by-zero when the size is unknown

v1: https://lore.kernel.org/r/20260912054706.1475583-1-namhyung@kernel.org

Thanks,
Namhyung


Cc: Zecheng Li <zli94@ncsu.edu>
Cc: Yanbo Zhao <yzhao62@ncsu.edu>
Cc: Tengda Wu <wutengda@huaweicloud.com>
Cc: Shuai Xue <xueshuai@linux.alibaba.com>

Namhyung Kim (4):
  perf dwarf-aux: Add die_has_flex_array() helper
  perf annotate-data: A small cleanup in __add_member_cb()
  perf annotate-data: Allow out-of-size access for flex-array types
  perf annotate-data: Adjust type offset for flex-array

 tools/perf/util/annotate-data.c | 192 ++++++++++++++++++++++++--------
 tools/perf/util/annotate-data.h |   6 +
 tools/perf/util/dwarf-aux.c     | 107 ++++++++++++++++++
 tools/perf/util/dwarf-aux.h     |   3 +
 4 files changed, 262 insertions(+), 46 deletions(-)

-- 
2.55.0

On Fri, Sep 18, 2026 at 11:37 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hello,
>
> The flexible arrays are dynamically allocated with different size.  So checking
> with the original type size won't match and cannot find the type if the offset
> is bigger than the size.  This patch series detects those flex-arrays and allows
> accesses beyong the original size.
>
> I'm not sure what's the best way to add test codes for data type profiling as it
> seems we need to add a lot more workloads for different cases.  Probably we may
> want to split the workloads as separate binaries.

We have tools/perf/tests/shell/data_type_profiling.sh, I wonder can we
not just have some workload with a:
```
struct flex_array {
   int len;
   int vals[];
};
```
then create a randomly sized flex array and access  it in a loop something like:
```
struct flex_array *a = calloc(sizeof(*a) + random_number * sizeof(int));
a->len = random_number;
while (!done) { /* done is set by an alarm like with noploop */
   for (int i = 0; i < a->len; i++) {
       a[i]++; /* Expect blame on struct flex_array here */
   }
}
```
ensuring the type profile blames the struct flex_array?

Thanks,
Ian

> v5 changes)
>
>  * add a cleanup patch
>  * add is_union and is_flex_array fields to find member correctly
>
> v4: https://lore.kernel.org/r/20260916061926.2224222-1-namhyung@kernel.org/
>
>  * update last member even if the offset is same
>  * handle type qualifiers in die_has_flex_array()
>  * add zero-length array members as flexible arrays
>  * check return value of strbuf_init() for type name
>
> v3: https://lore.kernel.org/r/20260915064035.1970175-1-namhyung@kernel.org
>
>  * patch 1 was merged!
>  * check if last member is found
>  * check member location when finding flex-array
>  * ensure member typename is initiailized
>  * fix a bug to pass a wrong type in check_variable()
>  * fix a typo in a comment
>
> v2: https://lore.kernel.org/r/20260914064535.1671939-1-namhyung@kernel.org
>
>  * fix missing index increment in the histogram
>  * support flex array in union types
>  * add recursion check in die_has_flex_array()
>  * check negative index arrays properly
>  * avoid divide-by-zero when the size is unknown
>
> v1: https://lore.kernel.org/r/20260912054706.1475583-1-namhyung@kernel.org
>
> Thanks,
> Namhyung
>
>
> Cc: Zecheng Li <zli94@ncsu.edu>
> Cc: Yanbo Zhao <yzhao62@ncsu.edu>
> Cc: Tengda Wu <wutengda@huaweicloud.com>
> Cc: Shuai Xue <xueshuai@linux.alibaba.com>
>
> Namhyung Kim (4):
>   perf dwarf-aux: Add die_has_flex_array() helper
>   perf annotate-data: A small cleanup in __add_member_cb()
>   perf annotate-data: Allow out-of-size access for flex-array types
>   perf annotate-data: Adjust type offset for flex-array
>
>  tools/perf/util/annotate-data.c | 192 ++++++++++++++++++++++++--------
>  tools/perf/util/annotate-data.h |   6 +
>  tools/perf/util/dwarf-aux.c     | 107 ++++++++++++++++++
>  tools/perf/util/dwarf-aux.h     |   3 +
>  4 files changed, 262 insertions(+), 46 deletions(-)
>
> --
> 2.55.0
>

On Sat, Sep 19, 2026 at 09:18:55AM -0700, Ian Rogers wrote:
> On Fri, Sep 18, 2026 at 11:37 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hello,
> >
> > The flexible arrays are dynamically allocated with different size.  So checking
> > with the original type size won't match and cannot find the type if the offset
> > is bigger than the size.  This patch series detects those flex-arrays and allows
> > accesses beyong the original size.
> >
> > I'm not sure what's the best way to add test codes for data type profiling as it
> > seems we need to add a lot more workloads for different cases.  Probably we may
> > want to split the workloads as separate binaries.
> 
> We have tools/perf/tests/shell/data_type_profiling.sh, I wonder can we
> not just have some workload with a:
> ```
> struct flex_array {
>    int len;
>    int vals[];
> };
> ```
> then create a randomly sized flex array and access  it in a loop something like:
> ```
> struct flex_array *a = calloc(sizeof(*a) + random_number * sizeof(int));
> a->len = random_number;
> while (!done) { /* done is set by an alarm like with noploop */
>    for (int i = 0; i < a->len; i++) {
>        a[i]++; /* Expect blame on struct flex_array here */
>    }
> }
> ```
> ensuring the type profile blames the struct flex_array?

Sure, I can add that.

But I was afraid it'd need many small workloads to check data type
profiling behavior for different aspects.  Maybe we can think about it
later when we need more. :)

Thanks,
Namhyung

On Sat, Sep 19, 2026 at 10:56 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Sat, Sep 19, 2026 at 09:18:55AM -0700, Ian Rogers wrote:
> > On Fri, Sep 18, 2026 at 11:37 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > Hello,
> > >
> > > The flexible arrays are dynamically allocated with different size.  So checking
> > > with the original type size won't match and cannot find the type if the offset
> > > is bigger than the size.  This patch series detects those flex-arrays and allows
> > > accesses beyong the original size.
> > >
> > > I'm not sure what's the best way to add test codes for data type profiling as it
> > > seems we need to add a lot more workloads for different cases.  Probably we may
> > > want to split the workloads as separate binaries.
> >
> > We have tools/perf/tests/shell/data_type_profiling.sh, I wonder can we
> > not just have some workload with a:
> > ```
> > struct flex_array {
> >    int len;
> >    int vals[];
> > };
> > ```
> > then create a randomly sized flex array and access  it in a loop something like:
> > ```
> > struct flex_array *a = calloc(sizeof(*a) + random_number * sizeof(int));
> > a->len = random_number;
> > while (!done) { /* done is set by an alarm like with noploop */
> >    for (int i = 0; i < a->len; i++) {
> >        a[i]++; /* Expect blame on struct flex_array here */
> >    }
> > }
> > ```
> > ensuring the type profile blames the struct flex_array?
>
> Sure, I can add that.
>
> But I was afraid it'd need many small workloads to check data type
> profiling behavior for different aspects.  Maybe we can think about it
> later when we need more. :)

Agreed, there may be a way to automate that. For the specific bug
where flex arrays fail to get type profiles we should be able to avoid
reproducing it with a simple test.

Thanks!
Ian

> Thanks,
> Namhyung
>