similar to: [LLVMdev] [lld] buildbot configuration on using -fsanitize options

There are existing Darwin and Win7 builders, and a few Debian configs that also build lld. I'd support enabling the sanitizers on these builds as is. Also, tsan especially because lld uses threads. If you'd like an Ubuntu bot, somebody is going to have to provide one. Alex On Sep 6, 2013, at 2:27 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi All, Chandler, >

Hi Alex, + Galina Ubuntu/Debian should work as well, I wanted one flavor where lld could be built on linux platform. I will want to have a seperate buildbot to seperate failures if any due to the fsanitize options. Do you know if llvm itself gets tested as a complete build with the fsanitize options ? Enabling tsan seems to be a good idea too. Thanks Shankar Easwaran On 9/8/2013 10:22

On 9/8/2013 11:48 PM, Chandler Carruth wrote: > On Sun, Sep 8, 2013 at 9:29 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Do you know if llvm itself gets tested as a complete build with the >> fsanitize options ? >> >> Enabling tsan seems to be a good idea too. >> > We test it very regularly with all of the sanitizers. We've not been

Does it build with libstdc++? I've got this with fresh clang, -std=c++11: In file included from ../projects/lld/lib/ReaderWriter/ELF/./SectionChunks.h:19: In file included from ../projects/lld/include/lld/Core/Parallel.h:28: In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:38:

FYI We have an upstream bootstrap bot ( http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap) that does a number of things including running llvm/clang tests under ASan/MSan. Probably we can add a couple of steps that would checkout lld and run check-lld in ASan-ified/MSan-ified build trees. On Mon, Sep 9, 2013 at 9:00 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:

Hi Evgeniy, Can you add the step to checkout lld and build and run the unittests then ? Thanks Shankar Easwaran On 9/10/2013 4:59 AM, Evgeniy Stepanov wrote: > Does it build with libstdc++? I've got this with fresh clang, -std=c++11: > > In file included from ../projects/lld/lib/ReaderWriter/ELF/./SectionChunks.h:19: > In file included from

On Sun, Sep 8, 2013 at 9:29 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Do you know if llvm itself gets tested as a complete build with the > fsanitize options ? > > Enabling tsan seems to be a good idea too. > We test it very regularly with all of the sanitizers. We've not been able to add these bots easily due to infrastructure issues. -------------- next

On 11/18/2013 11:57 AM, Mikael Lyngvig wrote: > I'm in the process of configuring a Mac Mini G4 (PowerPC, big-endian) to be > an LLD buildbot slave, as there were some who wanted a big-endian tester of > LLD. > > I have a few quick questions with respect to that: > > 1. LLD appears to be built using Clang, but Clang is not built as part of > the LLD build. So which

I'm in the process of configuring a Mac Mini G4 (PowerPC, big-endian) to be an LLD buildbot slave, as there were some who wanted a big-endian tester of LLD. I have a few quick questions with respect to that: 1. LLD appears to be built using Clang, but Clang is not built as part of the LLD build. So which version of Clang should I use? v3.3 or any nightly build of Clang. Is it enough that

It looks like there are errors in the buildbot runs with std::future_error when executing lot of tests, probably we can disable it for now to make the buildbot clean ? http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-ubuntu-13.04/builds/26755/steps/test/logs/stdio has more information. Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by

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

Yes, the Group is to represent --start-group,--end-group. So the group here will be contained in the linker Input as a vector of lld::files (foo.a, bar.a). thanks Shankar Easwaran On 9/4/2013 3:59 PM, Rui Ueyama wrote: > The first question is that Group is to represent --start-group/--end-group? > > If I understand your proposal correctly, here's the thing: if file is not > in

The --as-needed attribute is preserved and is contained within the ELF FileNode. By lld::files, I am referring to lld::File. Thanks Shankar Easwaran On 9/4/2013 4:10 PM, Rui Ueyama wrote: > On Wed, Sep 4, 2013 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Yes, the Group is to represent --start-group,--end-group. >> >> So the group here will

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this

Hi Nick, On 9/4/2013 4:04 PM, Nick Kledzik wrote: > I do think we have too many classes. Agree. > I thought InputGraph was going to replace InputFiles. Interesting idea. > It seems link LinkerInput could be merged into FileNode. Agree. > > Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods

On 10/4/2013 11:16 PM, Michael Spencer wrote: > On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Hi, >> >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is >> x86_64. Similiarly with other flavors. >> >> I was thinking

On Mon, Oct 14, 2013 at 8:41 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Wed, Oct 9, 2013 at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> Hi, >> >> We have a whole bunch of readers(we would have some more too), and was >> thinking if we should have a vector of Readers, and have a function >> isMyFormat in

On Wed, Sep 4, 2013 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > > Yes, the Group is to represent --start-group,--end-group. > > So the group here will be contained in the linker Input as a vector of > lld::files (foo.a, bar.a). It seems you dropped --as-needed attribute... ? By lld::files, what class are you pointing to, lld::File or lld::InputFiles?

+ Nick Rui, Does PECOFF writer need the filename in the writer as well, I am not sure if linker scripts are supported with PECOFF though. If PECOFF also needs it, I think it makes sense to store the filename in the Atom as the native format needs to store that information. The only option for the ELF writer to know this information is to use References if other flavors dont need the

I'm not planning to remove YAML. YAML is important for testing. On Fri, Feb 6, 2015 at 3:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am fine with it. I hope you are not planning to remove YAML. > > > On 2/6/2015 4:54 PM, Rui Ueyama wrote: > > Can we remove Native format support? I'd like to get input from anyone who > wants to keep the