Georg-Johann Lay <a...@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
