similar to: r338291 - Remove trailing space

No. A shared object is needed if it is linked in (1)--no-as-needed mode or (2) after --gc-sections, a symbol referenced by a live input section is defined by the shared object. You'll need to check whether a symbol is defined by libmvec.so.1 On Mon, Nov 9, 2020 at 9:57 AM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > On Mon, Nov 9, 2020 at 6:52 PM Fāng-ruì Sòng

lld/test/ELF/invalid/symtab-sh-info.s (check-lld-elf) is recently flaky on Windows, e.g. https://reviews.llvm.org/harbormaster/unit/view/192869/ http://45.33.8.238/win/27684/step_10.txt It fails like every 3 or 4 builds. Could someone with a Windows machine check what is going on? Is that due to output non-determinism (just my guess) in yaml2obj.exe? -------------- next part -------------- An

Thank you very much for your help Fāng-ruì Sòng. I've tried various things like linking directly to libm-2.32 but it didn't work, it seems that libm-2.32 still pulls libmvec. I have the following linker flags: CLANG_LDFLAGS="-fuse-ld=lld -static-libstdc++ -static-libgcc -fvisibility=hidden -fdata-sections -ffunction-sections" CLANG_LDFLAGS="$CLANG_LDFLAGS

On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Since you are going to rewrite the mlir history anyway, you can > probably delete accidentally checked in large files if any. > Good point, I checked and this is the largest file in the history of the repo as far as I can tell:

I can't send the exact objects, but I'll try to reproduce. Thanks A On 11/16/20, 9:48 AM, "Fāng-ruì Sòng" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza

This is a common pitfall: people think that .text is the first section of the traditional concept "text segment" (which does not apply with LLD layout and GNU ld's -z separate-code layout) You need to use --image-base=0 https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#breaking-changes On Mon, Nov 16, 2020 at 10:31 AM Moshtaghi, Alireza <Alireza.Moshtaghi at

My target requires that text section be at 0x0 so "-Ttext 0x0" is passed to the linker. When I link with gold, it goes through; but lld fails. Instead of always returning the same calculation, when I change the calculation to the following, it links: return first->offset + (os->addr > first->addr ? os->addr - first->addr :

On Wed, Nov 11, 2020 at 10:37 PM Fāng-ruì Sòng <maskray at google.com> wrote: > If you want to drop symbol versioning with llvm-objcopy: > > * llvm-objcopy -R .gnu.version -R .gnu.version_r in.so out.so > * However, llvm-objcopy zeroes out the section content so at runtime glibc ld.so will error > "unsupported version 0 of Verneed record". > Thus we need to

On 2020-09-03, Peter Collingbourne wrote: >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> On 2020-09-01, Petr Hosek wrote: >> >I see the GNU ld behavior as a limitation, not as a feature, as Peter >> Smith >> >also pointed out in https://reviews.llvm.org/D86762. While it can be >> argued

On 2020-09-01, Petr Hosek wrote: >I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith >also pointed out in https://reviews.llvm.org/D86762. While it can be argued >that there are certain cases where it can help detect layering >violations as you mentioned in your change, I'm not sure how valuable that >is in practice. Every case I've encountered so

On 2020-09-03, Peter Collingbourne wrote: >On Thu, Sep 3, 2020 at 2:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On 2020-09-03, Peter Collingbourne wrote: >> >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >> >llvm-dev at lists.llvm.org> wrote: >> > >> >> On 2020-09-01, Petr Hosek wrote: >> >> >I

On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > Would you like to conduct the conversation here, or on the review thread? (I lean

On Thu, Sep 3, 2020 at 5:15 PM Nico Weber <thakis at chromium.org> wrote: > I wanted to chime in and say that I think we should keep the current > default too, for three reasons: > > 1. The current default is more user friendly. Users shouldn't have to > worry about if they pass -lpthread before or after their .o files (...or > other libraries. I know I know for

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at

It looks like the conversation has died, but I just wanted to post my own investigation based on our internal code base. The code base itself is quite a sprawling mass, involving multiple different build systems, some bits CMake based, some hand-curated and so on, and I don't fully comprehend it all. I do know that trying to change it is hard at best, and more likely impossible to do so

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all

It did partially fix the issue but there is still one problem: llvm-objdump -sx gives: Version References: required from libpthread.so.0: 0x09691a75 0x00 05 GLIBC_2.2.5 0x09691972 0x00 09 GLIBC_2.3.2 0x09691973 0x00 07 GLIBC_2.3.3 0x06969192 0x00 12 GLIBC_2.12 required from libdl.so.2: 0x09691a75 0x00 21 GLIBC_2.2.5 required from libuuid.so.1: 0x09da27b0 0x00 19

I have made some further investigation. My conclusion is that GNU ld does not do better than lld. Making the --defsym behavior ideal is difficult in the current framework. GNU ld has some unintended behaviors. ld.bfd a.o --defsym 'd=foo' --gc-sections -o a => GNU ld retains .text_foo ld.bfd a.o --defsym 'd=foo+3' --gc-sections -o a => GNU ld drops .text_foo ld.bfd a.o

Like James, Michael suggested, I would prefer the default behavior be consistent across tools (either always read from stdin or no default at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t