Not all users compile their code with -ffunction-sections and -fdata-sections. This is to handle usecases when libraries use a mix of object files too. On 7/25/2013 4:10 PM, Rui Ueyama wrote:> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? > If it'll work, it may be be better to say "if you want to get a better > linker output use these options", rather than defining new ELF section. > > > On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 7/25/2013 3:56 PM, Rui Ueyama wrote: >> >>> I think I share the goal with you to make the foundation for better >>> dead-strip, so thank you for suggesting. I'm not sure if marking a section >>> as a whole as "safe" or "unsafe" is the best approach, though. Some >>> comments. >>> >>> - If the compiler generated code is always "safe", and if we can >>> distinguish it from hand-written assembly code by checking if there's a >>> gap >>> between symbols, can we just assume a section with no gap is always >>> "safe"? >>> >> Gaps could just be caused due to alignment, but the code may be safe, >> which the compiler knows very well. >> >> >> - "Safeness" is not an attribute of the section but of the symbol, I >>> think. The symbol is "safe" if there's no direct reference to the symbol >>> data. All references should go through relocations. A section may contain >>> both "safe" and "unsafe" symbols. >>> >> Sections contain symbols. In the context of ELF, marking sections as >> safe/not is more desirable because of the switches (-ffunction-sections and >> -fdata-sections available already). >> >> >> - How about making the compiler to create a new section for each "safe" >>> atom, as it does for inline functions? >>> >> You already have a switch called -ffunction-sections and -fdata-sections >> to put function and data in seperate sections. >> >> >>> On Thu, Jul 25, 2013 at 10:54 AM, Shankar Easwaran >>> <shankare at codeaurora.org>**wrote: >>> >>> Hi, >>>> Currently lld ties up all atoms in a section for ELF together. This >>>> proposal just breaks it by handling it differently. >>>> >>>> *This requires **NO ELF ABI changes. >>>> >>>> **Definitions :-* >>>> >>>> >>>> A section is not considered safe if there is some code that appears to be >>>> present between function boundaries (or) optimizes sections to place data >>>> at the end or beginning of a section (that contains no symbol). >>>> >>>> A section is considered safe if symbols contained within the section have >>>> been associated with their appropriate sizes and there is no data present >>>> between function boundaries. >>>> >>>> Examples of safe sections are, code generated by compilers. >>>> >>>> Examples of unsafe sections are, hand written assembly code. >>>> >>>> *Changes Needed :-* >>>> >>>> >>>> The change that I am trying to propose is the compiler emits a section, >>>> called (*.safe_sections) *that contains section indices on what sections >>>> >>>> are safe. >>>> >>>> The section would have a SHF_EXCLUDE flag, to prevent other linkers from >>>> consuming this section and making it to the output file. >>>> >>>> Data structure for this :- >>>> >>>> .safe_sections >>>> <total size> >>>> <section index> <boolean flag -- safe/unsafe> >>>> ... >>>> ... >>>> >>>> >>>> *Advantages >>>> *There are advantages that the atoms within a safe section could just be >>>> >>>> allocated in the output file which means better output file layout, and >>>> Better performance! >>>> >>>> This would also result in more atoms getting gc'ed. >>>> >>>> a) looking at profile information >>>> b) taking a order file >>>> >>>> *Changes needed in the assembler >>>> >>>> *a) add an additional flag in the section for people writing assembly >>>> >>>> code, to mark a section safe or unsafe. >>>> * >>>> **Changes needed in lld >>>> >>>> *a) Read the safe section if its present in the object file >>>> >>>> b) Tie atoms together within a section if the section is not safe >>>> * >>>> *Thanks >>>> >>>> Shankar Easwaran* >>>> >>>> * >>>> >>>> -- >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>>> hosted by the Linux Foundation >>>> >>>> >>>> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
Then how about enable these flags for -O2? I want to hear from other people cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF section if there's other mean already available to achieve the same thing. On Thu, Jul 25, 2013 at 2:12 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> Not all users compile their code with -ffunction-sections and > -fdata-sections. > > This is to handle usecases when libraries use a mix of object files too. > > > > On 7/25/2013 4:10 PM, Rui Ueyama wrote: > >> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? >> If it'll work, it may be be better to say "if you want to get a better >> linker output use these options", rather than defining new ELF section. >> >> >> On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On 7/25/2013 3:56 PM, Rui Ueyama wrote: >>> >>> I think I share the goal with you to make the foundation for better >>>> dead-strip, so thank you for suggesting. I'm not sure if marking a >>>> section >>>> as a whole as "safe" or "unsafe" is the best approach, though. Some >>>> comments. >>>> >>>> - If the compiler generated code is always "safe", and if we can >>>> distinguish it from hand-written assembly code by checking if there's a >>>> gap >>>> between symbols, can we just assume a section with no gap is always >>>> "safe"? >>>> >>>> Gaps could just be caused due to alignment, but the code may be safe, >>> which the compiler knows very well. >>> >>> >>> - "Safeness" is not an attribute of the section but of the symbol, I >>> >>>> think. The symbol is "safe" if there's no direct reference to the symbol >>>> data. All references should go through relocations. A section may >>>> contain >>>> both "safe" and "unsafe" symbols. >>>> >>>> Sections contain symbols. In the context of ELF, marking sections as >>> safe/not is more desirable because of the switches (-ffunction-sections >>> and >>> -fdata-sections available already). >>> >>> >>> - How about making the compiler to create a new section for each >>> "safe" >>> >>>> atom, as it does for inline functions? >>>> >>>> You already have a switch called -ffunction-sections and >>> -fdata-sections >>> to put function and data in seperate sections. >>> >>> >>> On Thu, Jul 25, 2013 at 10:54 AM, Shankar Easwaran >>>> <shankare at codeaurora.org>****wrote: >>>> >>>> >>>> Hi, >>>> >>>>> Currently lld ties up all atoms in a section for ELF together. This >>>>> proposal just breaks it by handling it differently. >>>>> >>>>> *This requires **NO ELF ABI changes. >>>>> >>>>> **Definitions :-* >>>>> >>>>> >>>>> A section is not considered safe if there is some code that appears to >>>>> be >>>>> present between function boundaries (or) optimizes sections to place >>>>> data >>>>> at the end or beginning of a section (that contains no symbol). >>>>> >>>>> A section is considered safe if symbols contained within the section >>>>> have >>>>> been associated with their appropriate sizes and there is no data >>>>> present >>>>> between function boundaries. >>>>> >>>>> Examples of safe sections are, code generated by compilers. >>>>> >>>>> Examples of unsafe sections are, hand written assembly code. >>>>> >>>>> *Changes Needed :-* >>>>> >>>>> >>>>> The change that I am trying to propose is the compiler emits a section, >>>>> called (*.safe_sections) *that contains section indices on what >>>>> sections >>>>> >>>>> are safe. >>>>> >>>>> The section would have a SHF_EXCLUDE flag, to prevent other linkers >>>>> from >>>>> consuming this section and making it to the output file. >>>>> >>>>> Data structure for this :- >>>>> >>>>> .safe_sections >>>>> <total size> >>>>> <section index> <boolean flag -- safe/unsafe> >>>>> ... >>>>> ... >>>>> >>>>> >>>>> *Advantages >>>>> *There are advantages that the atoms within a safe section could just >>>>> be >>>>> >>>>> allocated in the output file which means better output file layout, and >>>>> Better performance! >>>>> >>>>> This would also result in more atoms getting gc'ed. >>>>> >>>>> a) looking at profile information >>>>> b) taking a order file >>>>> >>>>> *Changes needed in the assembler >>>>> >>>>> *a) add an additional flag in the section for people writing assembly >>>>> >>>>> code, to mark a section safe or unsafe. >>>>> * >>>>> **Changes needed in lld >>>>> >>>>> *a) Read the safe section if its present in the object file >>>>> >>>>> b) Tie atoms together within a section if the section is not safe >>>>> * >>>>> *Thanks >>>>> >>>>> Shankar Easwaran* >>>>> >>>>> * >>>>> >>>>> -- >>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>>>> hosted by the Linux Foundation >>>>> >>>>> >>>>> >>>>> -- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >>> by the Linux Foundation >>> >>> >>> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/e7175329/attachment.html>
On 25 July 2013 17:24, Rui Ueyama <ruiu at google.com> wrote:> Then how about enable these flags for -O2? I want to hear from other people > cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF > section if there's other mean already available to achieve the same thing.I would probably support doing that first. A small annoyance is that the linker requires the --gc-sections option, but most current gnu (bfd and gold) versions support that, so we should be fine at least on linux (and the driver already collects the distro we are in anyway in case we need to change the default for some old distro). Once that is in, the existing proposals for splitting sections into atoms become speed and relocatable object size optimizations. Cheers, Rafael