Bug 24201 - Potential problems with HOT_TEXT_SECTION_NAME
Summary: Potential problems with HOT_TEXT_SECTION_NAME
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.3
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-04 21:45 UTC by H.J. Lu
Modified: 2012-01-11 14:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-11 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2005-10-04 21:45:31 UTC
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?
Comment 1 Andrew Pinski 2005-10-04 21:52:30 UTC
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.
Comment 2 H.J. Lu 2005-10-04 22:36:25 UTC
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.
Comment 3 Andrew Pinski 2005-10-04 22:41:06 UTC
(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.
Comment 4 H.J. Lu 2005-10-04 22:58:20 UTC
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.
Comment 5 Andrew Pinski 2005-10-04 23:14:40 UTC
(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.
Comment 6 H.J. Lu 2005-10-05 00:37:33 UTC
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.