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
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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/8f07e594/attachment.html>
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
On Jul 25, 2013, at 2: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.>From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in the .o file which the linker must process.For reference, with mach-o we just added a flag to the overall .o file that says all sections are "safe". The compiler always generates safe object files (unless there is inline code with non-local labels) and always sets the flag. Hand written assembly files did not have the flag by default, but savvy assembly programmers can set it. -Nick