Displaying 20 results from an estimated 2000 matches similar to: "Bug 26222 - [ELF] wrong functions are called when linking against DSO"
2017 Dec 16
3
[RFC] - Deduplication of debug information in linkers (LLD).
?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
Тема:
2020 Oct 02
2
[EXTERNAL] Re: preferred way to return expected values
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:
2018 Mar 21
2
[LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
>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:
2018 Feb 09
2
Collecting address ranges in DWARFUnit::collectAddressRanges.
>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
2020 Oct 02
2
[EXTERNAL] Re: preferred way to return expected values
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
>
>
2018 Feb 09
2
Collecting address ranges in DWARFUnit::collectAddressRanges.
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
2017 Oct 02
4
Should we switch to --hash-style=both by default in LLD ?
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
2017 Oct 02
1
Should we switch to --hash-style=both by default in LLD ?
> 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
2018 Feb 09
0
Collecting address ranges in DWARFUnit::collectAddressRanges.
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
2018 Mar 22
0
[LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
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
2017 Dec 16
2
[RFC] - Deduplication of debug information in linkers (LLD).
>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
2020 Oct 01
2
[EXTERNAL] Re: preferred way to return expected values
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;
>
2020 Feb 03
2
[RFC][FileCheck] New option to negate check patterns
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
2020 Feb 04
2
RFC: Add a preprocessor to yaml2obj (and other YAML tools)
?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
2016 Oct 21
2
LLD: creating linker-generated sections as input sections instead of output sections
> Is anyone already working on it? If not then I can take this task.
Me - not.
George.
2016 Mar 16
2
LLD performance w.r.t. local symbols (and --build-id)
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.
2016 May 31
3
Bug 23231 - support symbol version script / --version-script option
Hi Rui,
If you do not have active development on symbol versioning currently,
I think I can start working on this, after some more investigations.
What do you think ?
Best regards,
George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160531/cc74537b/attachment.html>
2016 Mar 16
2
LLD performance w.r.t. local symbols (and --build-id)
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
2017 Jan 24
5
Linking Linux kernel with LLD
>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.
>
>
2017 Feb 03
3
Linking Linux kernel with LLD
On Thu, Feb 2, 2017 at 12:38 AM, George Rimar <grimar at accesssoftek.com>
wrote:
> >As far as the setup, I would recommend setting up qemu for actually
> running the LLD-linked kernel and custom bootloader etc. because then you
> can have a single >script that rebuilds the bootloader and kernel and
> copies the files to the VM. This reduces iteration time significantly.