On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote:> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >> 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. > We could set this flag for ELF too in the ELF header, but it wouldnot not confirm to the ELF ABI. > > To account safe sections, we should just create an additional section in the ELF (gcc creates a lot many sections to handle executable stack and for LTO). This would just be another section to dictate what sections are safe.Or just create a new empty section with a magic name whose existence tells the linker that all sections are safe.> Isnt it better to have this flag set for every section in Darwin too, makes it flexible. I am not sure about the ABI concerns on Darwin though.I don't see the benefit of that level of detail. Either the compiler produced the object file, so all sections are safe. Or it was hand written. If hand written, it is much easier to either say all sections are safe or none are. Listing which are safe and which are not would be a pain. -Nick
On 7/30/2013 5:43 PM, Nick Kledzik wrote:> On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> 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. >> We could set this flag for ELF too in the ELF header, but it wouldnot not confirm to the ELF ABI. >> >> To account safe sections, we should just create an additional section in the ELF (gcc creates a lot many sections to handle executable stack and for LTO). This would just be another section to dictate what sections are safe. > Or just create a new empty section with a magic name whose existence tells the linker that all sections are safe. > >> Isnt it better to have this flag set for every section in Darwin too, makes it flexible. I am not sure about the ABI concerns on Darwin though. > I don't see the benefit of that level of detail. Either the compiler produced the object file, so all sections are safe. Or it was hand written. If hand written, it is much easier to either say all sections are safe or none are. Listing which are safe and which are not would be a pain.I can think of two usecases when the compiler needs to emit safe sections on a section by section basis. * code having inline assembly (it only affects the text section) * the compiler trying to do some optimizations that deals with data placed outside function boundaries. Does this make sense ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
I've not been following this thread at all. However, skimming the original post, I fail to find a nice summary of what problem is trying to be solved. By reading the rest of the thread I divine that the goal is faster links and better dead code stripping? Making that clearer would help. Naming your sections something other than "safe" (which has *very* different connotations) would help more. However, I question several fundamental assumptions: 1) We should be very certain that -ffunction-sections is not a viable solution as it exists and is well supported in other toolchains and environments. 2) We should talk to other ELF producers and coordinate to make sure we don't end up creating a twisty maze of extensions here. 3) We should step back and consider leapfrogging to a fully specialized format to reap even more performance benefits rather than messily patching ELF. #3 may prove irrelevant if this is the only major hurdle for speeding up ELF links. My impression was otherwise. #2 hasn't been done by the other ELF producers, but we should strive to do better. #1 can be solved via science. On Tue, Jul 30, 2013 at 5:33 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 7/30/2013 5:43 PM, Nick Kledzik wrote: > >> On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: >> >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> >>>> 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. >>>> >>> We could set this flag for ELF too in the ELF header, but it wouldnot >>> not confirm to the ELF ABI. >>> >>> To account safe sections, we should just create an additional section in >>> the ELF (gcc creates a lot many sections to handle executable stack and for >>> LTO). This would just be another section to dictate what sections are safe. >>> >> Or just create a new empty section with a magic name whose existence >> tells the linker that all sections are safe. >> >> Isnt it better to have this flag set for every section in Darwin too, >>> makes it flexible. I am not sure about the ABI concerns on Darwin though. >>> >> I don't see the benefit of that level of detail. Either the compiler >> produced the object file, so all sections are safe. Or it was hand written. >> If hand written, it is much easier to either say all sections are safe or >> none are. Listing which are safe and which are not would be a pain. >> > I can think of two usecases when the compiler needs to emit safe sections > on a section by section basis. > > * code having inline assembly (it only affects the text section) > * the compiler trying to do some optimizations that deals with data placed > outside function boundaries. > > Does this make sense ? > > > Thanks > > Shankar Easwaran > > -- > 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/20130730/f665eec1/attachment.html>
Can you guys invent a more specific word than "safe" to describe this concept? The best thing I can come up with is something like "atomizable section". This is basically describing code and data that the linker should feel free to strip and reorder, right? I'm not tracking this closely enough to be totally sure if that's a reasonable word for this. On Tue, Jul 30, 2013 at 5:33 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 7/30/2013 5:43 PM, Nick Kledzik wrote: > >> On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: >> >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> >>>> 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. >>>> >>> We could set this flag for ELF too in the ELF header, but it wouldnot >>> not confirm to the ELF ABI. >>> >>> To account safe sections, we should just create an additional section in >>> the ELF (gcc creates a lot many sections to handle executable stack and for >>> LTO). This would just be another section to dictate what sections are safe. >>> >> Or just create a new empty section with a magic name whose existence >> tells the linker that all sections are safe. >> >> Isnt it better to have this flag set for every section in Darwin too, >>> makes it flexible. I am not sure about the ABI concerns on Darwin though. >>> >> I don't see the benefit of that level of detail. Either the compiler >> produced the object file, so all sections are safe. Or it was hand written. >> If hand written, it is much easier to either say all sections are safe or >> none are. Listing which are safe and which are not would be a pain. >> > I can think of two usecases when the compiler needs to emit safe sections > on a section by section basis. > > * code having inline assembly (it only affects the text section) > * the compiler trying to do some optimizations that deals with data placed > outside function boundaries. > > Does this make sense ? > > > Thanks > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/fd17d7ac/attachment.html>