>> > 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
