Group static constructors and destructors in specific subsections

[Cary Coutant]

>> > Yep, the problem is where to produce the section ordering file.
>> > The scheme is as follows:
>> >   - with -fprofile-generate instrument every function entry point and record
>> >     time of first and last invocation of the functoin
>> >   - At compile time we take functions that are executed during the startup
>> >     and we want to order them in the increasing order of the first invocation
>> >     time measured at FDO time. So we know the relative position of given function
>> >     in the program, but not the complette function order.
>>
>> Perhaps I misunderstand, but you can use --section-ordering-file
>> without knowing the complete function ordering.  Just specify the
>> functions you care about.
>
> The thing is that when compiling given object file, you know only functions in
> that object file, so you can not produce full --section-ordering-file.  We
> would need a tool colleting the partial orders from all objects to single file
> that I think may be just done in linker.

How granular a solution do you need? If you need something fine-grain,
like microseconds since startup, we'd also need some way of ensuring
that all compilation units are using the same scale. What if someone
else wants to order by execution count instead? We could do something
coarse-grain by adding a few more "buckets" after "unlikely", "exit",
"startup", and "hot", but you probably would need to see the whole
program before you could translate something like time-since-startup
into a bucket.

In another old thread, I suggested modifying the section naming
convention to remove the ambiguity between a function named "unlikely"
compiled with -ffunction-sections, and an arbitrary function placed
into the "unlikely" bucket. Namely, instead of using
".text.function_name" and ".text.bucket", we combine these into
".text.bucket.function_name". Without -ffunction-sections, we'd just
have ".text.bucket" like we do today, but with -ffunction-sections,
we'd have ".text..function_name" in the case where there is no bucket.
In order to distinguish between old and new conventions, I'd amend
that suggestion to use a different set of delimiters -- perhaps
".text[bucket](function_name)". That at least makes it more obvious
that the input section goes into an output section named ".text", and
we can have a general rule rather than the collection of special cases
we have now.

To support your use case, we could allow, in addition to the four
buckets we already have defined, numeric buckets ranging from, say, 0
to 99999. You could map whatever ordering criterion you want to use
into that range, and the linker would order the text sections by
bucket, placing the numbered buckets after "hot" and before all the
unbucketed sections. I might further suggest moving "unlikely" to the
end, after all the unbucketed sections.

(I can't believe I'm suggesting this -- I don't like the increasing
effect that section names have on the linker behavior, but I don't
think we really have any better options in ELF.)

As an aside, is there any reason why the function name must appear in
the section name when we use -ffunction-sections? ELF doesn't require
sections to have unique names, so they could all be named ".text". We
could do section reordering based on the symbol names rather than the
section names, so it's not necessary for reordering. As far as I can
tell, it's just an assembler limitation, which we could fix by
modifying the syntax of the .section directive to allow both an
assembler name and a linker name. All those function names just bloat
the section string table for no good reason.

-cary