similar to: Bug 23231 - support symbol version script / --version-script option

Hi ! During linking LLD and other linkers builds a static hash table for dynamic symbols, so that in runtime dynamic linker can use this table and find symbols faster. --hash-style=style linker option is used to select the hash type: "Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU

?But could not we for example do split dwarf, but for example do dedup of types ? I do not mean right now, but in a theory ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема:

On Fri, Oct 2, 2020 at 1:48 AM George Rimar <grimar at accesssoftek.com> wrote: > Thanks, David! > > > Few minor additions to the topic: > > > > I'm not sure which MSVC version on godbolt would be "MSVC 2017" that > the LLVM docs refer to > > > I've found that the minimal available version of MSVC on > godbolt is "WINE MSVC 2015:

?Hi, I found a new issue in lld (https://llvm.org/bugs/show_bug.cgi?id=26222), but after review of outputs internals still have no idea why that can happen. Do you have any thoughts about possible reasons of that ? I am going to continue investigating that tomorrow. Best regards, George. -------------- next part -------------- An HTML attachment was scrubbed... URL:

>I think we should wait until there is someone wanting to use these features with lld. > >Cheers, >Rafael Ok. Should we give an error when .note.gnu.property section is in the object?? ?Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL:

>Totally fair call, sorry it took me a while to come back around to this - added in r324702 Thanks ! Have a question: does it need "requres shell" ? I tried without and it worked for me under windows (had to change check to CHECK: .{{\\|/}}test.cpp:2:51 though). And I see nothing special probably that might require shell I think. We use cd/rm/cp in LLD testcases without requiring

Yeah, not sure either. The discussion about minimum compatibility usually comes down to what version is available on long-term OS releases. On Fri, Oct 2, 2020 at 12:38 PM George Rimar <grimar at accesssoftek.com> wrote: > > Is the code currently broken? > > > I don't know. Perhaps the code is fine, I did not try to compile LLVM > with all that compilers > >

I expect r324738 will break on windows, as I mentioned I had to change CHECK: ./test.cpp:2:51 to CHECK: {\\|/}}test.cpp:2:51 ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 9 февраля 2018 г. 18:35 Кому: George Rimar Копия: Robinson, Paul; llvm-dev at lists.llvm.org; Rafael Avila de Espindola

> Le 2 oct. 2017 à 14:23, George Rimar <grimar at accesssoftek.com> a écrit : > > I think we can switch LLD either to "both" or probably to "gnu" by default as well. > Initial version of patch that changes default to "both" is here: D38407 > > Any thoughts ? > > Best regards, > George | Developer | Access Softek, Inc Hi, I

Nah, doesn't look like it. Removed it (& the place I copied it from) in: r324738 Thanks! On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com> wrote: > >Totally fair call, sorry it took me a while to come back around to this - > added in r324702 > > Thanks ! Have a question: does it need "requres shell" ? > I tried without and it

I'd think we shouldn't do anything even for printing out a warning unless doing it is proved to be useful. On Wed, Mar 21, 2018 at 1:04 AM George Rimar <grimar at accesssoftek.com> wrote: > >I think we should wait until there is someone wanting to use these > features with lld. > > > >Cheers, > >Rafael > > Ok. Should we give an error when

>Wasn't our (lld/ELF's) position on debug info size that we should focus on providing a great split-dwarf workflow and not try go too far out of our way to deduplicate >or otherwise reduce debug info size inside LLD? I recall there being some patches that made linking of large debug binaries like 1.5GB+ clang faster, but we decided to >reject those changes because split-dwarf was

On Thu, Oct 1, 2020 at 2:08 AM George Rimar <grimar at accesssoftek.com> wrote: > FWIW, I've performed an experiment with the code below at godbolt. > (used -O2, https://godbolt.org/z/nY95nh) > > ``` > #include <vector> > #include "llvm/Support/Error.h" > > llvm::Expected<std::vector<int>> foo() { > std::vector<int> V; >

Thanks for the suggestions. I think the naming the whole line idea is okay, but it feels a bit clunky. Either we'd have to have a syntax that FileCheck would recognise without caring about the prefix (which seems to be against the ethos of FileCheck, and also makes it less flexible), or in the case I'm referring to, we'd have to have an extra line that does nothing other than define

?The idea itself is indeed good. Regarding to escaping: I think we should have it. Imagine the following example (I've took it from D73828). --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2LSB Type: ET_EXEC Machine: EM_386 # RUN: yaml2obj %s --docnum=4 -D BITS=32 -o %t-32bit.o # RUN: yaml2obj %s --docnum=4 -D BITS=64 -o %t-64bit.o Without escaping it would

> Is anyone already working on it? If not then I can take this task. Me - not. George.

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back. Best regards, George.

Hi, Rafael took some measurements to try to investigate the effect of the local symbols changes. I've been taking a look at the measurements he got and there were some interesting things we noticed. For starters, in the range of revisions tested (r263214 through r263471), we found that the commit for --build-id was the most noticeable, with slowdowns from 7% to 23% (note: these were

>Our tokenizer recognize > > [A-Za-z0-9_.$/\\~=+[]*?\-:!<>]+ > >as a token. gold uses more complex rules to tokenize. I don't think we need that much complex rules, but there seems to be >room to improve our tokenizer. In particular, I believe we can parse the Linux's linker script by changing the tokenizer rules as >follows. > >

​Hi all, > I feel it might be confusing to have a CHECK becomes effectively a CHECK-NOT, > especially if the RUN line is far from the CHECK line (which is often the case when > a single RUN line drives several groups of CHECK directives (e.g. code generation > tested for several functions for a specific feature, like PIC). You also loose control > on where the NOT should be: