What goes into function_rodata_section

[Ian Lance Taylor]

Georg-Johann Lay <avr@gjlay.de> writes:

>> chosen so that the rodata is grouped with the function, so that if the
>> function is discarded the associated rodata is also discarded.  That
>> grouping is what the linkonce stuff is about.
>
> Is there a description of that concept somewhere? Didn't find it on the web or
> in GCC wiki or in gcc sources.

For the general concept, look for SHT_GROUP.  I don't know if its use in
gcc is documented anywhere.


>> In practice you are correct that the only read-only data associated with a
>> specific function is the jump table (for targets for which 
>> JUMP_TABLES_IN_TEXT_SECTION is false).  In principle the section could be
>> used for targets with function-specific constant pools, but targets which
>> use those tend to put the constant pool in the text section anyhow.
>
> JUMP_TABLES_IN_TEXT_SECTION is false and there are no constant pools for that
> target.  Still I'm wondering about the condition
>
>     flag_function_sections && flag_data_sections
>
> in varasm.c:default_function_rodata_section where I'd just expected
>
>     flag_function_sections
>
> as it's data, but bound to specific function and not user-defined.  So
> -fdata-sections might not be desired to take advantage of constant merging; yet
> you'd like to get rid of unused switch tables just by means of -ffunction-sections.

I don't know why default_function_rodata_section is testing
flag_data_sections.  I agree that that looks odd.

Ian