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
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. 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. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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 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? -eric
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