Hey, just cause SoC is over doesn't mean i'm not happy to answer your questions to the degree I can, so please, keep cc'ing me.
That's great, thanks :)
> I'd like to get your feedback about design of frontend-specific type > tag infrastructure in gengtype. > > First of all, how things are done currently in WIP version: > 1) A big enum is created for all the gengtype-recognized types in > gtype-desc.h, regardless of the frontend they belong to. > 2) A big array of function pointers is declared for the same set of > types in gtype-desc.h and initialized in gtype-desc.c with > automatically generated names for marker functions. > 3) A new set of marker functions is generated. They are dispatched to > the output files using the common old > get_output_file_with_visibility() logic, i.e. frontend-specific > functions go to the frontend-specific generated files, not > gtype-desc.*. > > This setup is flawed: the array in gtype-dec.c is initialized using > function pointers that do not resolve at compilation time. It's not clear to me why this is true, if the array is initialized with auto-generated marker-names. What functions do not resolve, exactly?
For example, when cc1-dummy is linked: libbackend.a(gtype-desc.o):(.rodata+0x588): undefined reference to `gt_tggc_mx_prod_token_parm_item' This is a name of my marker procedure for struct prod_token_parm_item, which is defined in treelang/treelang.h. The prototype for this function is written to the global gtype-desc.h file, and implementation to gtype-treelang.h, which is included by treelang/tree1.c, which is naturally not linked in to cc1-dummy. Note how including prototypes to the global gtype-desc.h moves this error from compilation to link time. -- Thanks, Laurynas
