We have #define HOT_TEXT_SECTION_NAME ".text.hot" #define UNLIKELY_EXECUTED_TEXT_SECTION_NAME ".text.unlikely" There is a little potential for confusion, for example suppose we have a very hot function with the unlikely name of "unlikely" or a very cold function called "hot". With -ffunction-sections, we got [hjl@gnu-13 hot]$ cat x.c void hot () { } void unlikely () { } [hjl@gnu-13 hot]$ gcc -c x.c -ffunction-sections [hjl@gnu-13 hot]$ readelf --wide -S x.o | grep text [ 1] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4 [ 4] .text.hot PROGBITS 0000000000000000 000040 000006 00 AX 0 0 1 [ 5] .text.unlikely PROGBITS 0000000000000000 000046 000006 00 AX 0 0 1 Should we use a slightly different standard naming scheme so as to distinguish the special names such as huge, hot and unlikely from the function naming cheme?
I don't see why this is really a problem. It only effects the gcing sections, it just means you are not going to remove those functions when used with other functions which are in the hold/cold section.
The problem is with -ffunction-sections, we may put a very big cold function in the .text.hot section and a very hot function in the .text.unlikely section. It defeats the whole purpose of .text.hot/.text.unlikely.
(In reply to comment #2) > The problem is with -ffunction-sections, we may put a very big cold function in > the .text.hot section and a very hot function in the .text.unlikely section. It > defeats the whole purpose of .text.hot/.text.unlikely. But -ffunction-sections disables the use hot/unlikely sections so what is the problem? Maybe you should not be mixing code compiled with and without -ffunction-sections.
A library may be compiled with -ffunction-sections. It doesn't mean that all codes linked against that library have to use -ffunction-sections. For example, libstdc++ is compiled with -ffunction-sections. Do I have to use it for all programs linked against libstdc++? A better naming scheme can help this.
(In reply to comment #4) > A library may be compiled with -ffunction-sections. It doesn't mean that all > codes linked against that library have to use -ffunction-sections. For example, > libstdc++ is compiled with -ffunction-sections. Do I have to use it for all > programs linked against libstdc++? A better naming scheme can help this. but libstdc++ is dynamic/shared library so it should not matter with respect linking.
I used libstdc++ as an example to show that it isn't unreasonable to have .o files compiled with and without -fffunction-sections. Besides, on my system there is a libstdc++.a. We can just use something like #define HOT_TEXT_SECTION_NAME ".text..hot" #define UNLIKELY_EXECUTED_TEXT_SECTION_NAME ".text..unlikely" to avoid this issue.
Note HOT_TEXT_SECTION_NAME/UNLIKELY_EXECUTED_TEXT_SECTION_NAME are no longer, They are part of default_function_section now. Note I suspect if we change the names in varasm.c, we need to change the default linker script in binutils to do the same. The big question is who defines a function named hot/unlikely/startup (Note exit is already named as a standard C function which is for the exit so that is ok).