This is the mail archive of the
mailing list for the GCC project.
Re: How to tag frontend-specific types?
Laurynas Biveinis wrote:
>> 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
>>> 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
Ah yes, now i remember.
> 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.
When i had made it auto-generate the marker arrays, i somehow got it to
split the things out into the right language files, and that seemed to
work out okay.
it did, as you've pointed out, have the problem that you couldn't link
multiple frontends into the same executable, but i think that's fine for
the forseeable future.