similar to: [lld] Flavour option purpose

Displaying 20 results from an estimated 20000 matches similar to: "[lld] Flavour option purpose"

2017 Oct 26
2
[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: >
2017 Oct 26
1
[lld] Flavour option purpose
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
2017 Nov 01
2
[lld] Flavour option purpose
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
2017 Nov 01
2
[lld] Flavour option purpose
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
2017 Nov 14
2
[lld] Flavour option purpose
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
2017 Nov 16
2
[lld] Flavour option purpose
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
2015 Feb 09
2
[LLVMdev] lld options to parse linker script
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>
2013 Jan 24
3
[LLVMdev] [lld] driver and options questions
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
2017 Mar 29
3
Invoking lld for PE/COFF (Windows) linking
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
2014 Dec 02
5
[LLVMdev] Making llvm-objdump more like GNU objdump
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
2013 Oct 31
3
[LLVMdev] Current state of the lld project
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
2014 Oct 07
5
[LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?
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 Nov 01
0
[LLVMdev] Current state of the lld project
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
2013 Oct 10
2
[LLVMdev] [lld] Handling a whole bunch of readers
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
2013 Oct 10
2
[LLVMdev] [lld] Handling a whole bunch of readers
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
2013 Oct 11
2
[LLVMdev] [lld] Handling a whole bunch of readers
# 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
2014 Oct 08
2
[LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?
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 >
2015 Sep 03
2
lld on Windows
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
2015 Sep 03
2
lld on Windows
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
2015 Oct 01
4
lld and thread over-subscription
----- 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 > >