search for: flavor

...hat 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 support. c) Printing all the targets/flavors that the linker currently supports. On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> Hi, >> >> I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets. > This sounds like...

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 > assumptions of behavior based on flavor. > > If I want to cross-compile from OS X for Windows PECOFF, I don't think...

...9;-l' option to see license information for software included in this program. Running test using CCITT FAX test page, US letter size, 204x196 resolution, MMR encoding, ECM enabled and V.17 (14.4kbps) modem NOTE: Each individual test could take 20 seconds or longer; be patient. Test run 1 for flavor 'i686' used 632 milliseconds of CPU time. Test run 2 for flavor 'i686' used 604 milliseconds of CPU time. Test run 3 for flavor 'i686' used 656 milliseconds of CPU time. Test run 4 for flavor 'i686' used 207 milliseconds of CPU time. Test run 5 for flavor 'i686...

Hi, I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets. For this I was thinking that the Registry expand to consider flavors and targets that are part of the build process. So each flavor/target would register and the Driver would walk through the list of handlers to check if there is a handler defined for that flavor/target....

...he 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 using lld with PE/COFF on Windows at https://lld.llvm.org/windows_support.html: "LLD supports Windows operating system. When invoked as lld-link.exe or with -flavor link, the driver for Windows operating system is used to parse command line options, and it drives further linking processes. LLD accepts almost all command line options that the linker shipped with Microsoft Visual C++ (link.exe) supports." Unfortunately with clang++ attempting to use &qu...

Hi all, According to lld/docs/Driver.rst, Flavor command line option determines the style of lld command-line interface when invoked. However, it looks like this option also determines the set of supported targets we are linking for. For example, lld -flavor gnu cannot link mach-o binaries, and could not link PE binaries either (well, not until...

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 new DarwinDriver cla...

...xtension? >> >> >> I would like to support usecases like this. > > (a) > $ cat simple.s > .text > .global _start > .type _start, at function > _start: > callq bar > ret > > clang simple.s -c- -o- | lld -flavor gnu -target x86_64 > --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - > > Which is certainly not doable because you dont have a file created on the > filesystem. > This is an interesting example but I doubt the actual value of doing that, especially because it cannot h...

...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 think using ld.lld or lld-link is preferred way over "lld -flavor gnu" > or "lld -flavor link". > > -flavor seems to be still actively used in Clang… By the the way, there > seems to be no special > command name for Darwin targets, so ld.lld (incorrectly) invokes the ELF > linker there > (see https://bugs.llvm.org/show_bug.cgi?...

..., g wrote: > > > On 06/07/2015 07:25 PM, Kay Schenk wrote: > <<>> > >> So, I'm not sure how to interpret what you said. Can I get the same >> results from a CentOS install using some combination of options? > > because your are playing with multi flavors, > [i bet you like going to baskin-robbins for ice cream ;-) ] > a solution for you would be what i did some years back and i was > playing with diff flavors, my "/home" partition was mounted in > new install as /home2 and i let installation setup a /home in /. > > af...

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L...

...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 think using ld.lld or lld-link is preferred way over "lld -flavor gnu" > or "lld -flavor link". > > -flavor seems to be still actively used in Clang… By the the way, there > seems to be no special > command name for Darwin targets, so ld.lld (incorrectly) invokes the ELF > linker there > (see https://bugs.llvm.org/show_bug.cgi?...

...; >>> (a) >>> $ cat simple.s >>> .text >>> .global _start >>> .type _start, at function >>> _start: >>> callq bar >>> ret >>> >>> clang simple.s -c- -o- | lld -flavor gnu -target x86_64 >>> --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - >>> >>> Which is certainly not doable because you dont have a file created on the >>> filesystem. >>> >>> This is an interesting example but I doubt the actua...

...enefit of depending on special file magic compared to using file extension? > > I would like to support usecases like this. (a) $ cat simple.s .text .global _start .type _start, at function _start: callq bar ret clang simple.s -c- -o- | lld -flavor gnu -target x86_64 --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - Which is certainly not doable because you dont have a file created on the filesystem. PS: This has been snipped from an earlier discussion with Tim. (b) lld -flavor gnu -target x86_64 input.o --output-filetype=y...

...would like to support usecases like this. >> (a) >> $ cat simple.s >> .text >> .global _start >> .type _start, at function >> _start: >> callq bar >> ret >> >> clang simple.s -c- -o- | lld -flavor gnu -target x86_64 >> --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - >> >> Which is certainly not doable because you dont have a file created on the >> filesystem. >> > This is an interesting example but I doubt the actual value of doing that, > e...

On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > 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. Sounds fine. We also need to figure how to determine when ld mea...

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. > > As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. > > The options that are shared between Darwin/GnuLD a...

...e a fixed file extension anyway (we probaly don't want to use .txt for YAML object file for example), so what do you think is the benefit of depending on special file magic compared to using file extension? You would also be able to figure out if the yaml file is a valid input for >> the flavor/target too. >> > > Ping ? > > > Shankar Easwaran > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc...

...simple.s >>>> .text >>>> .global _start >>>> .type _start, at function >>>> _start: >>>> callq bar >>>> ret >>>> >>>> clang simple.s -c- -o- | lld -flavor gnu -target x86_64 >>>> --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - >>>> >>>> Which is certainly not doable because you dont have a file created on the >>>> filesystem. >>>> >>>> This is an interesting exam...

...ave some questions about wiring it up. Currently the instantiated Driver transforms the command line arguments in to "core" arguments which is passed to generatedOptions() to construct a LinkerOptions object. >> >> Is the plan for LinkerOptions to contain the superset of all flavor's options? That seems like it won't scale well. In particular if you are using lld as a library and you want to programmatically create a LinkerOptions, it is unclear which options need to be set for a particular flavor. >> >> It seems like the concrete subclass of TargetInf...