similar to: when will LLD be included with LLVM releases?

On 4 February 2017 at 02:58, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think that LLD is going to be included in the 4.0 release. At least, we've > been cherry-picking fixes into the release branch. I've CC'd some others > that will know the details. The test-release.sh script still doesn't have it and I believe it's just because we never

I see in that code review page that LLD is built in the test-release script. Happy to see that. Now I'm thinking about package maintainers such as Debian, and hoping that they will pick up LLD and make it available with this next release. What is different about this release that will clue Debian developers and other package managers that they should include LLD with this release? How can we

On May 29, 2015, at 10:08 PM, Rui Ueyama <ruiu at google.com> wrote: > Large part of the difficulties in development of the current LLD comes from over-generalizataion to share code between pretty much different file formats. ISTM the problem that's been described isn't that code is shared between file formats, but that an internal representation was chosen based on what MachO

Hi Tanya, Could you add 4 basic categories "COFF", "ELF", "MachO",under the "LLD" product? (we already have "All Bugs" so really only 3 categories need to be added). That will help keep things organized. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, May 29, 2015 at 8:29 PM, James Y Knight <jyknight at google.com> wrote: > > On May 29, 2015, at 10:08 PM, Rui Ueyama <ruiu at google.com> wrote: > > Large part of the difficulties in development of the current LLD comes > from over-generalizataion to share code between pretty much different file > formats. > > ISTM the problem that's been described

MachO support in lld is not really ready for real world usage. It was able to bootstrap itself a couple of years ago, but, it has not really been maintained or further developed since. I would recommend that you use ld64 if you are intending to build MachO binaries. > On Jan 7, 2018, at 9:57 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm seeing

Hi, llvm developers. I can't find a lld-dev mail list, so just mail to here. ld in macOS is legacy, lld a more modern linker. I have test, `-fuse-ld=lld, -Wl,--as-needed `, but its output is: /usr/local/bin/ld.lld: error: unknown argument: -dynamic /usr/local/bin/ld.lld: error: unknown argument: -arch /usr/local/bin/ld.lld: error: unknown argument: -search_paths_first

On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > It has been said in this thread before, but I fail to see how the atom > model is an actual improvement over the fine grained section model. It > seems to be artifically restricted for no good reasons. Sections come with a huge amount of bloat and overhead that atoms do not. >> Lets stop

On Mon, May 04, 2015 at 12:52:55PM -0700, Chris Lattner wrote: > I think the problem here is that these lead to natural and inescapable > tensions, and Alex summarized how Camp B has been steering LLD away > from what Camp A people want. This isn’t bad in and of itself, because > what Camp B wants is clearly and unarguably good for LLVM. However, > it is also not sufficient, and

Replying to the thread, not just the email since I was on vacations. First, note that there is a nomenclature issue. A section in ELF/COFF is closer to an atom in MachO than a MachO section IMHO. A rose by any other name would smell as sweet, but sure as hell creates a lot of confusion :-) On 4 May 2015 at 18:05, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2015, at 1:16

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

Hello, I am working in an embedded environment with somewhat restrictive memory requirements where the page alignment requirements of an ADRP instruction cannot be guaranteed. With the ld program inside of the Xcode, there is a -preload flag which causes ADRP instructions to be dropped, and generates code that is 100% position independent. As near as I can determine, ld.lld does not have this

I'm seeing something similar. clang is using HOST_LINK_VERSION, obtained from ld64, as the default for -mlinker-version. This causes Darwin.cpp to add the arguments you are seeing, but not handled by lld. Perhaps -fuse-ld should be considered in addition to -mlinker-version when adding these arguments. As a workaround, you can try passing -mlinker-version. Looks like anything < 133

Hi all, We’re planning to contribute a new implementation of LLD for Mach-O, using the same design as the COFF and ELF ports. This design has proven to work very well for those ports, and we’re keen to explore it for Mach-O as well. Our work is based on an initial prototype created by Peter Collingbourne and Rui Ueyama. Our initial commit is up for review at https://reviews.llvm.org/D75382.

Suppose i write // foo.cpp __attribute__((section(“foo”))) int x; // bar.cpp __attribute__((section(“foo”))) int y; And i compile and link these two object files together using lld. What assumptions can I make regarding alignment/padding between the two symbols? I’m comfortable getting an answer by reading the source, but that won’t tell if any properties i discover are guaranteed or just

Hi Eric, On 21 May 2018 at 13:31, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am working in an embedded environment with somewhat restrictive memory > requirements where the page alignment requirements of an ADRP instruction > cannot be guaranteed. It sounds like you're relying on the linker optimization hints that Clang emits. As you've seen they're

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

I filed this bug today: https://bugs.llvm.org/show_bug.cgi?id=32376 I understand that the Mach-O linker is not under active development, but there must be some way to work around this bug. Does anyone have a clue? This trivial IR file gives "dyld: lazy symbol binding failed: bad lazy bind info" at runtime when linked with: lld -flavor darwin -demangle -dynamic -arch x86_64

Hello all, I'm trying to better understand the state of Mach-O support in lld. The lld docs state that "the linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and WebAssembly in descending order of completeness." [1] True to that statement, I found an email on this list from Jan 2018 stating that "MachO support in lld is not really ready for real world usage. It was

Ok, thanks! I got it going that way. I'd still love to hear from anyone off list working on similar stuff. ~Scott On Sun, Apr 30, 2017, at 03:32 PM, Joerg Sonnenberger wrote: > On Sun, Apr 30, 2017 at 03:18:35PM -0700, Scott Shawcroft via llvm-dev > wrote: > > Hi all, > > I've been doing a ton of embedded work (bare metal ARM Cortex M0+ and > > M4, hopefully RISCV