similar to: [lld] Flavour option purpose

Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to have been interested in it enough to actually invent and implement a set of unified command line arguments. On Thu, Oct 26, 2017 at 2:20 PM, N <scandium at me.com> wrote: >

I mean, there is such a universal driver -- it's called "clang". On Oct 26, 2017 5:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> wrote: Martell recently added "ld64.lld" as a name for the Darwin driver. As to why there's no driver that provides a unified command line arguments, I can't speak for other people. But no one seems to

On 11/1/17 10:29 AM, N via llvm-dev wrote: > Thank you for your answers. > > Indeed, Clang is universal, but only until one needs to pass some commands to the linker which are not > automatically passed by the driver. Then we are back to the same problem. Clang and GCC both support the `-Wl,` and `-Xlinker` flags... Jon > > In my opinion, it would be great if lld had a

Most command line options in GNU, macOS and MSVC are not just different in terms of notion but different in terms of semantics. For example, MSVC link.exe doesn't have --start-group and --end-group options because their symbol resolution semantics are different than Unix. link.exe on the other hand doesn't have --init or --fini options because that's ELF-only concept. Linker scripts

On Mon, Nov 13, 2017 at 9:31 PM, N <scandium at me.com> wrote: > > For example, MSVC link.exe doesn't have --start-group and --end-group > options because their symbol resolution semantics are different than Unix. > > Yes, but this is specific for a linker, not for a target. For example, GNU > ld supports this option for all binary formats. A linker with universal CLI

On Wed, Nov 15, 2017 at 10:45 PM, N <scandium at me.com> wrote: > > You can't really remove any native linker-compatible command line > interface unless you get agreement from all parties including Microsoft and > Apple to switch to the GNU command line as the universal interface in the > future versions of their toolchains. > > I completely agree; that's why I

Hi all, Which are the command-line options available to pass linker script, library path etc.. to lld? I see minimal options listed, when i say, lld -flavor gnu -help Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/e7a6f7b8/attachment.html>

Michael, I'm looking at flushing out the mach-o driver and targetinfo. Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once lld takes over, the term ld64 won't mean anything. I've worked through adding DarwinOpts.td

I build llvm/clang/lld from source on Windows using mingw-64/gcc-6.3. I use clang++ both to test clang targeting gcc and clang targeting VC++. When using clang targeting VC++ I use the appropriate target triple when compiling and am trying to use lld to link the object file(s) into an exe. To do that I use the clang option "-fuse-ld=lld" when linking. According to the llvm doc on

Hey folks, This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style for ELF). Kevin’s

Hello list, on the lld main page at http://lld.llvm.org, it says: "lld is in its early stages of development. It can currently self host on Linux x86-64 with -static." Is this information up-to-date? I'm interested in using lld on Windows (win32 on PC) with object files created by llvm (no clang involved). Is that possible at this time? It would be awesome to be able to create a

On 10/7/2014 4:10 PM, Nick Kledzik wrote: > Shankar, > > Can you give provide a scenario where you want this? I’m not sure what you want here. a) LLVM could be built just for one target(LLVM_TARGETS_TO_BUILD) b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not

2013/10/31 Daniel Albuschat <d.albuschat at gmail.com>: > on the lld main page at http://lld.llvm.org, it says: > > "lld is in its early stages of development. > It can currently self host on Linux x86-64 with -static." > > Is this information up-to-date? I made a quick test on a Windows 8 64bit system: test.c: int main () { return 42; } > clang -c test.c

On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 11:19 PM, Rui Ueyama wrote: > >> >> Isnt having a YAML file starting with the below better, so that you dont >> need to go through file extensions. >> >> magic : >> arch: >> >> I guess we will use a fixed file extension anyway (we probaly

On Wed, Oct 9, 2013 at 7:57 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > >> On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> >>> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> >>> wrote: >>> >>>> We have a whole bunch of readers(we would have

# is a line comment chracter in YAML so it's valid. That's why I wrote a simple magic "comment". On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/10/2013 5:00 PM, Rui Ueyama wrote: > >> On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On

On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > This it totally "armchair quarterbacking," but I am a little frustrated > that we've come to conflate flavors and targets. > > The original intent of flavors was to internally translate each flavor > into a neutral lld-native command line syntax. We now have baked in >

Ah! I don't know what GUARDSYM does or whether there is any way to turn it off at the compiler end; a Google search doesn't seem to find anything; but it would be great if you could add support for msvc 2015. When I try using clang as the compiler, I get a different error message. In this case it seems to be just not finding the standard libraries? C:\t>clang -c a.c C:\t>lld

C:\t>type a.c #include <stdio.h> int main() { puts("hello"); return 0; } C:\t>cl /c a.c Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x64 Copyright (C) Microsoft Corporation. All rights reserved. a.c C:\t>lld Select the appropriate flavor OVERVIEW: LLVM Linker USAGE: lld [options] <inputs> OPTIONS: -core CORE linking -flavor

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >