On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote:> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> 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. >> > > Drive by comment here: > > Other than the overhead of the section header I'm not sure what bloat > you're talking about here that the linker needs to process?The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). If an object file has a hundred functions, that means there will be a hundred more sections (one per function). So, if we used -ffunction-sections to determine that an object file was compiler generated, we still have the problem that an assembly language programmer could have hand written extra sections that look like -ffunction-sections would have produced, but he did something tricky like have one function with two entry symbols. So, the linker would need to double check all those hundred sections. -Nick
On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote:> > On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: >> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> 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. >>> >> >> Drive by comment here: >> >> Other than the overhead of the section header I'm not sure what bloat >> you're talking about here that the linker needs to process? > > The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). >I'll stipulate all of this :)> If an object file has a hundred functions, that means there will be a hundred more sections (one per function). So, if we used -ffunction-sections to determine that an object file was compiler generated, we still have the problem that an assembly language programmer could have hand written extra sections that look like -ffunction-sections would have produced, but he did something tricky like have one function with two entry symbols. So, the linker would need to double check all those hundred sections. >I'm not talking about using -ffunction-sections to determine if something is compiler generated, just that there's no inherent penalty in using -ffunction-sections in general. Basically there's no benefit (unless you allow a flag per object, etc) that says whether or not something is "compiler generated", you may as well just use a flag to the linker or a section in the output (the latter is a fairly common elf-ism). -eric
On 7/30/2013 7:50 PM, Eric Christopher wrote:> On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote: >> On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote: >>> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> 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. >>>> >>> Drive by comment here: >>> >>> Other than the overhead of the section header I'm not sure what bloat >>> you're talking about here that the linker needs to process? >> The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). >> > I'll stipulate all of this :) > >> If an object file has a hundred functions, that means there will be a hundred more sections (one per function). So, if we used -ffunction-sections to determine that an object file was compiler generated, we still have the problem that an assembly language programmer could have hand written extra sections that look like -ffunction-sections would have produced, but he did something tricky like have one function with two entry symbols. So, the linker would need to double check all those hundred sections. >> > I'm not talking about using -ffunction-sections to determine if > something is compiler generated, just that there's no inherent penalty > in using -ffunction-sections in general. Basically there's no benefit > (unless you allow a flag per object, etc) that says whether or not > something is "compiler generated", you may as well just use a flag to > the linker or a section in the output (the latter is a fairly common > elf-ism).When you consider the complete link line (consisting of multiple archives and object files), you may not have all of them compiled with -ffunction-sections and -fdata-sections. Its also a problem that third party vendors would provide a library which may / may not be compiled with that flag. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation