Am Mittwoch, dem 09.04.2025 um 18:31 +0000 schrieb Qing Zhao:
> Hi, Joseph and Martin,
>
> When I implemented the patch to attach the counted_by information to an array
> reference (FAM reference) in C FE,
> The work was done inside the routine “build_component_ref” in
> gcc/c/c-typeck.cc <http://c-typeck.cc/>. and this is very reasonable and
> quite clean.
>
> Now, If we try to replace a structure pointer reference with counted_by
> attached to the FAM field, where in the C FE
> I should look at?
>
> For the following small example, I am trying to replace the pointer reference
> at line 28, “obj”, and line 34, “q” to a call to
> .ACCESS_WITH_SIZE. However, “p” at line 21 and “q” at line 33 should not be
> replaced.
>
> Do you have any suggestions?
>
> Thanks a lot for your help here.
Hi Qing,
sorry, I wasn't able to follow the thread. If I understand correctly,
you want to extend the reach of BDOS by using the information from
counted_by, but not only for the size of the FAM but also for the
size of the struct itself, for scenarious where BDOS can not find
the original allocation. Is this correct?
I have some questions about this: The access would add new reads
to the size field. For counted_by, so far, those are somehow
coupled to the access to the member. From this you would assume
that inserting the new accesses to the size field are ok (e.g.
one can assume the struct is accessible, there are no new race
conditions under some assumptions, it is initialized). If you
now want to read the size at different points, all this is even
less clear to me.
I may miss something, but I think one would have to first
define a clear criterion when it is ok to access the size
field.
So to me it seems we can not simply insert it at specific
point in the C FE where a pointer to the struct is
used, but only when there is some specific trigger.
An example I could imagine is when you memcpy
the struct. (but it is also not entirely clear why this
should not be allowed to go beyond the counted_by size
if the underlying storage is larger).
Maybe you could add it when a pointer to an annotated
struct is passed as parameter, but also there it is not
clear to me that we might want to materialize new
accesses to the struct at this point.
An alternative approach could be to just do it when
such a pointer is explicitely passed to the BDOS builtin.
Martin
>
> Qing
>
> 1 #include <stdlib.h>
> 2 #include <stddef.h>
> 3
> 4 struct annotated {
> 5 size_t count;
> 6 char array[] __attribute__((counted_by (count)));
> 7 };
> 8
> 9 /* compute the minimum # of bytes needed to hold a structure “annotated”,
> 10 whose # of elements of “array” is COUNT. */
> 11 #define MAX(A, B) (A > B) ? (A) : (B)
> 12 #define ALLOC_SIZE_ANNOTATED(COUNT) \
> 13 MAX(sizeof (struct annotated), \
> 14 offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))
> 15
> 16 /* allocate the memory for the structure with FAM,
> 17 update “count” with the # of elements “index”. */
> 18 static struct annotated * __attribute__((__noinline__)) alloc_buf (int
> index)
> 19 {
> 20 struct annotated *p;
> 21 p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
> 22 p->count = index;
> 23 return p;
> 24 }
> 25
> 26 static size_t __attribute__((__noinline__)) size_of (struct annotated *
> obj)
> 27 {
> 28 return __builtin_dynamic_object_size (obj, 1);
> 29 }
> 30
> 31 int main()
> 32 {
> 33 struct annotated *q = alloc_buf (10);
> 34 __builtin_printf ("the bdos whole is %d\n", size_of (q));
> 35 return 0;
> 36 }
>
>
