search for: icfes

Hi Peter, This is a great proposal, thanks!. If you were worried about making the abi change have you thought about just going for an array of symbol names or hashes of symbol names where any matching symbol is considered address significant? This would sidestep the problem of keeping the symbol table indices in sync. It would be pessimistic for local symbols if the input SHT_ADDRSIG sections

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan

Hello, I think that the approach of using a section to record address significance is a good one. I'm guessing it will have its own section type and format? If it does would it make sense to try and submit this to the GABI https://groups.google.com/forum/#!forum/generic-abi as it could be potentially useful for other linkers, for example gold? Happy to help out with reviews. Peter On 22

On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> wrote: > Hello, > > I think that the approach of using a section to record address > significance is a good one. I'm guessing it will have its own section > type and format? If it does would it make sense to try and submit this > to the GABI https://groups.google.com/forum/#!forum/generic-abi as

Hi Peter, Thanks for doing this! On Wed, May 23, 2018 at 3:07 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >> >>> Hello,

On Thu, May 24, 2018 at 10:24 AM, Eric Christopher <echristo at gmail.com> wrote: > Hi Peter, > > Thanks for doing this! > > On Wed, May 23, 2018 at 3:07 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >>

On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> > wrote: > >> Hello, >> >> I think that the approach of using a section to record address >> significance is a good one. I'm guessing it will have its own section >> type and format? If

On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >> >>> Hello, >>> >>> I think that the approach of using a

On Tue, May 22, 2018 at 6:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only to sections which can be safely merged according to the guarantees > provided by the language. It works using a set of heuristics (symbol name > matching and relocation scanning).

On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Wed, May 23, 2018 at 3:25 AM, Peter

On Thu, May 31, 2018 at 5:13 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Wed, May 23, 2018 at

>Hi folks, > >Our LLVM compiler creates a special debug section, which depends on a >certain >text section. This debug section is created with the SHF_LINK_ORDER >flag, and >sh_link field in the section header points to the correct section. > >When linking the program with the linker flag '-gc-sections', lld can >garbage- >collect unused sections. In my

It seems that showing eh_frame section pieces in the map file is useful, but I wonder what would be a concrete use case of the feature. Do you mind if you ask you to describe your plan if you have a use case in mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from,

On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> > wrote: > > > > > > > -----Original Message----- > > > > From:

On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> wrote: > On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via

On 23 May 2018 at 23:07, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: >> >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >>> >>> Hello, >>> >>> I think that the approach of using a

On Mon, Sep 30, 2019 at 1:27 PM Eric Christopher <echristo at gmail.com> wrote: > On Mon, Sep 30, 2019 at 12:31 PM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam

I've been working on the new LLD COFF linker for 1.5 months so far (including history of my personal repository), and I feel like I should post an update on that matter as a followup to the previous discussion thread. In short, it's doing very well. Completeness It was able to link itself from the first day when the first patch was landed. Since then, I fixed bugs and added more

I guess Eric means full program optimization/cross module optimization using MIR. This is in theory workable in full LTO style, but not in ThinLTO style which works on summary data. As we have discussed, eliminating monolithic style optimization is the key design goal. This was also briefly discussed in one of the previous replies I sent. There are other benefits of doing this in linker such