Ian Lance Taylor wrote:
> Georg-Johann Lay <a...@gjlay.de> writes:
>
>> Implementing TARGET_ASM_FUNCTION_RODATA_SECTION hook I wonder that will go
>> into these sections an I am a but unsure as the internals don't say a word
>> about that. From the only two uses of that hook in final.c I would
>> conclude that it's only used for jump tables generated by switch/case
>> statements.
>>
>> The default returns readonly_data_section which is not correct for AVR;
>> the avr BE did override this to switch to appropriate section in
>> ASM_OUTPUT_ADDR_VEC_ELT and ASM_OUTPUT_BEFORE_CASE_LABEL.
>> ASM_OUTPUT_BEFORE_CASE_LABEL alone won't do because the switch to
>> function_rodata_section takes place after that hook.
>>
>> So I'd like to reassure me that the function_rodata_hook is only used for
>> jump tables and not for other stuff so that I can clean up the avr BE at
>> that point. From what I found it's not used for vtables, but for all the
>> linkonce stuff I couldn't find comprehensive explanantion.
>
> TARGET_ASM_FUNCTION_RODATA_SECTION is in principle used for any read-only
> data associated only with a specific function. For most targets this is
Constant lookup tables from tree-switch-conversion don't go there; there is no
mechanism to put these in specific sections (I had a bit trouble with that when
implementing a named address space for Harvard AVR where .rodata is part or RAM
and RAM is very scarce.) Actually, putting constant switch tables into
function_rodata_section instead of in readonly_data_section would break avr BE.
> 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.
> 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.
> TARGET_ASM_FUNCTION_RODATA_SECTION is not used for vtables. That would not
> make sense, as vtables are not function-specific.
>
> Ian
Johann
