This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hot/cold vs glibc

On Apr 18, 2005, at 8:35 AM, Daniel Jacobowitz wrote:

Hi Caroline,

You've made this change to assemble_start_function (unidiff format):

+ last_text_section = no_section;
+ in_section = no_section;
resolve_unique_section (decl, 0, flag_function_sections);
+ /* Switch to the correct text section for the start of the function. */
function_section (decl);
+ if (flag_reorder_blocks_and_partition
+ && !hot_label_written)
+ ASM_OUTPUT_LABEL (asm_out_file, hot_section_label);

Why did you need to reset in_section? This causes an extra .text to be
emitted before every function. It also breaks the (ugly, non-unit-at-a-time
compatible, but otherwise working) mechanism that glibc uses to generate
crti.o and crtn.o, so I can no longer build a mips64-linux toolchain using

That was because, up until very recently, the call to function_section there
used in_section to partially determine which section to switch to. In the
code just above the bit in your email, there were switches to the hot/cold
sections to properly set alignments for the function and to insert the
hot/cold start labels. Those calls to switch sections also set the value for
in_section. I needed to blank it out again so that function_section would
go to the correct section.

I believe the current implementation of function_section no longer depends
on the value of in_section, so you could probably remove that line
without any adverse affects.

Just out of curiousity, could you be more explicit about exactly how having
an extra .text breaks the mechanism? That worries me...

-- Caroline

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]