Hi Pavel, Jonas,
I was trying to reduce a bug through c-reduce, so I decided to write a SBAPI
script to make it easier.
I did find out, that after the first iteration, the reduction gets stuck
forever.
I sampled the process and I saw the following (trimmed for readability).
Call graph:
[…]
On Thu, Oct 31, 2019 at 1:06 PM Pavel Labath via lldb-dev
wrote:
>
> (Just writing to say that tomorrow is a public holiday in most of
> Europe, so I wont be able to meaningfully reply to this until
> monday/tuesday. But if, in the mean time, you want to revert this, or
> just limit the scope of t
Thanks for the explanation. + Pavel & Adrian.
On Thu, Oct 31, 2019 at 12:51 PM Jim Ingham via lldb-dev
wrote:
>
> It looks like this change is causing problems with swift. I was talking a
> little bit with Davide about this and it seems like it wasn't obvious how
> this was designed to work.
On Wed, Oct 30, 2019 at 11:52 AM Jim Ingham via lldb-dev
wrote:
>
> Except of course without the comment markers...
>
> > On Oct 30, 2019, at 11:36 AM, Jim Ingham wrote:
> >
> > Anyway, another way to do this would be something like:
> >
> > #if (${LLVM_DEFAULT_TARGET_TRIPLE})
> > string(REGEX M
Presumably Pavel and Michal (both cc'ed).
On Fri, Oct 11, 2019 at 3:06 PM António Afonso via lldb-dev
wrote:
>
> Hi,
>
> All the *nix build bots (lldb-x86_86-{debian,fedora}, netbsd-amd64) have been
> offline for a while now. Some as far as July 12.
> I’m not sure if this is being tracked or wh
On Fri, Aug 30, 2019 at 1:44 AM Raphael “Teemperor” Isemann via
lldb-dev wrote:
>
> Hi all,
>
> I have to admit I’m getting a bit confused lately where to put tests.
> Especially for testing LLDB commands it’s not obvious where to put files as
> we test some commands directly in the top-level te
On Wed, Aug 14, 2019 at 11:27 AM Adrian McCarthy via lldb-dev
wrote:
>
> A recent change is causing several LLDB tests on Windows to fail and several
> more to time out, which I intend to look into.
>
> It appears the timeout period is set to 600 seconds (10 minutes), which seems
> excessive and
On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> We're using it with Eclipse and Eclipse based product, so I'd like to keep
> as well! :-)...
>
> Zdenek
>
I do understand that there's desire from people to keep this around (from
an user perspective),
On Mon, Jul 1, 2019 at 3:21 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really
> like to keep it! 😊
>
>
>
Is there any reason why this can't be a downstream project?
Thanks,
--
Davide
+ Stella/Pavel
On Fri, May 31, 2019 at 8:42 AM Alexandre Ganea via lldb-dev
wrote:
>
> Hi,
>
>
>
> I can’t seem to run the lldb python tests on my Windows 10 setup. I use the
> following cmd-line to generate:
>
>
>
> cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release
> -DLLVM_OPTIMIZED_TABLE
After discussing this privately with Pavel we decided to try updating
pexpect instead.
On Tue, Feb 26, 2019 at 4:42 AM Pavel Labath wrote:
>
> On 25/02/2019 22:15, Davide Italiano wrote:
> > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
> >>
> >> On 21/02/2019 19:48, Ted Woodward wrote:
>
I'm in favor of this. FWIW, I will be surprised if lldb works at all
with that option.
On Thu, Mar 7, 2019 at 10:28 AM Adrian McCarthy via lldb-dev
wrote:
>
> We have a build option to build LLDB without Python. This option is
> automatically set if Cmake can't find or "validate" your Python di
On Thu, Mar 7, 2019 at 7:04 AM Gábor Márton via lldb-dev
wrote:
>
> Hi guys,
>
> I've seen that recently the test
> lldb-Suite.macosx/queues.TestQueues.py fails non-deterministically.
>
> E.g.
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21271/testReport/
> http://green.lab.llvm.org/
I think this might have been fixed, try to pull.
On Tue, Mar 5, 2019 at 3:10 AM Gábor Márton via lldb-dev
wrote:
>
> Hi,
>
> On trunk I receive the following build error on Linux:
> ../../git/llvm/tools/lldb/include/lldb/lldb-forward.h:181:7: note:
> forward declaration of 'lldb_private::ProcessI
On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl via lldb-dev
wrote:
>
>
>
> On Feb 25, 2019, at 10:21 AM, Zachary Turner via lldb-dev
> wrote:
>
> Hi all,
>
> We've got some internal efforts in progress, and one of those would benefit
> from debug info parsing being out of process (independently o
On Mon, Feb 25, 2019 at 1:57 PM Adrian Prantl wrote:
>
>
>
> > On Feb 25, 2019, at 1:40 PM, Davide Italiano wrote:
> >
> > On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote:
> >>
> >>
> >>
> >>> On Feb 25, 2019, at 1:15 PM, Davide Italiano
> >>> wrote:
> >>>
> >>> On Fri, Feb 22, 2019 at 6:3
On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote:
>
>
>
> > On Feb 25, 2019, at 1:15 PM, Davide Italiano wrote:
> >
> > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
> >>
> >> On 21/02/2019 19:48, Ted Woodward wrote:
> >>>
> >>>
> -Original Message-
> From: lldb-dev O
On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
>
> On 21/02/2019 19:48, Ted Woodward wrote:
> >
> >
> >> -Original Message-
> >> From: lldb-dev On Behalf Of Pavel Labath
> >> via lldb-dev
> >> Sent: Thursday, February 21, 2019 8:35 AM
> >> To: Davide Italiano
> >> Cc: LLDB
> >> Sub
On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath wrote:
>
> On 31/01/2019 19:51, Zachary Turner wrote:
> > FileCheck the ansi escape codes seems like one possibility.
> >
> > In general I think you don't actually need to test true interactivity,
> > because the odds of there being a problem in th
On Thu, Jan 31, 2019 at 10:09 AM Pavel Labath wrote:
>
> On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote:
> > As you probably know (I didn’t), lldb embeds its own version of
> > `pexpect-2.4`, which doesn’t support python3.
> > This is the (relatively short)
As you probably know (I didn’t), lldb embeds its own version of
`pexpect-2.4`, which doesn’t support python3.
This is the (relatively short) list of tests relying on pyexpect:
testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
# 7 (EOF)
testcases/tools/ll
On Fri, Jan 11, 2019 at 3:07 PM Stella Stamenova wrote:
>
> Thanks Davide,
>
> I think several of these bots have not been maintained for a while. One thing
> we could do is try to ping the owners and see if it's possible to update the
> bots or if they're no longer useful, then remove them.
>
On Fri, Jan 11, 2019 at 9:20 AM via lldb-dev wrote:
>
> Inspired by people recently asking about or filing bugs for test fails
> that happen in their own environments, I thought I might do the same.
> "But wait," I thought, "maybe some bots are already finding these."
>
> Which led me to discover:
On Thu, Jan 10, 2019 at 12:43 AM Pavel Labath via lldb-dev
wrote:
>
> On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote:
> > The Native PDB symbol file plugin I think is mostly complete. It's at
> > least almost as good as the old Windows-only PDB plugin in 90% of ways,
> > while actually be
On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev
wrote:
>
> On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss wrote:
>>
>>
>>
>> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny wrote:
>> >
>> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss wrote:
>> > -llvm-dev + lldb-dev for the lldv test fai
On Fri, Jan 4, 2019 at 3:54 PM Zachary Turner wrote:
>
> It seems like we have 3 uses of this constructor in LLDB.
>
> IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant.
> IRForTarget.cpp: Constructs a Scalar for an llvm::Constant.
> ClangASTContext.cpp: bitcasts an APFloat to an APInt
On Fri, Jan 4, 2019 at 1:57 PM Davide Italiano wrote:
>
> While adding support for 512-bit integers in `Scalar`, I figured I
> could add some coverage.
>
> TEST(ScalarTest, Signedness) {
> auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
> auto s2 = Scalar(APInt(32, 12, true /* isSigned */
While adding support for 512-bit integers in `Scalar`, I figured I
could add some coverage.
TEST(ScalarTest, Signedness) {
auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
auto s2 = Scalar(APInt(32, 12, true /* isSigned */ ));
ASSERT_EQ(s1.GetType(), Scalar::e_uint); // fails
ASSERT_EQ(s
On Sun, Dec 16, 2018 at 5:50 PM Davide Italiano wrote:
>
> [cross-posting this to llvm-dev for better visibility]
>
> I got a private mail from a student (prospective GSoC) who asked me
> what was the best way to start contributing to lldb. So, I decided to
> take some bugs and mark them as beginn
[cross-posting this to llvm-dev for better visibility]
I got a private mail from a student (prospective GSoC) who asked me
what was the best way to start contributing to lldb. So, I decided to
take some bugs and mark them as beginner, as there were none for the
specific component).
https://bugs.l
On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev
wrote:
>
> I was puzzled by the behavior of ArchSpec::IsExactMatch() and
> IsCompatibleMatch() yesterday, so I created a couple of unit tests to
> document the current behavior. Most of the tests make perfect sense, but a
> few edge case
On Thu, Dec 6, 2018 at 6:39 AM Gábor Márton wrote:
>
> Hi Davide,
>
> Thank you for your email.
>
> > In particular, what's the error you get when lldb fails immediately running
> > the tests?
> > Also, have you checked libcxx and libcxx-abi in your build? We might
> > consider making that a mand
Follow up. This turned out to be a bug in the swift specific support,
so I don't think the DWARF parser code is wrong here.
Thanks!
--
Davide
On Thu, Oct 11, 2018 at 10:52 AM Davide Italiano wrote:
>
> Hi Greg,
> I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
> I wa
On Thu, Oct 11, 2018 at 1:38 PM Greg Clayton wrote:
>
> I am happy to look at any DWARF expressions you have and help figure out
> where the change needs to go or how the expression need to be fixed.
>
Thank you for your help, it's greatly appreciated. hopefully we'll
have a more precise debugge
On Thu, Oct 11, 2018 at 11:16 AM Greg Clayton wrote:
>
> The issue is DW_OP_deref dereferences a pointer and pushes it onto the stack.
> The code currently, for a load address that is on top of the stack does:
>
> Value::ValueType value_type = stack.back().GetValueType();
> switch (value_type) {
Hi Greg,
I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
I wasn’t able to craft an easy C++ testcase, so I’ll start from my
motivating (swift) example.
Given the following code:
func use(_ t : T) {}
func single(_ t : T) {
let x = t
use(x)
}
let s = "hello"
single(
On Tue, Oct 9, 2018 at 3:56 AM Chirag Patel via lldb-dev
wrote:
>
> Hello all,
>
>
>
> I am looking into adding the new typesystem support for languages like
> PLI/COBOL.
>
> Is anybody actively working/looking on this?
>
>
>
> Regards,
>
>
Not I'm aware of.
--
Davide
___
On Wed, Sep 19, 2018 at 8:35 PM Venkata Ramanaiah Nalamothu via
lldb-dev wrote:
>
> Hi,
>
> After compiling an example.cpp file with "-c -ffunction-sections" and linking
> with "--gc-sections" (used ld.lld), I am still seeing debug info for the
> sections deleted by garbage collector in the gene
On Thu, Sep 13, 2018 at 2:56 AM René J.V. Bertin via lldb-dev
wrote:
>
> Hi,
>
> clang has this nice runtime OS version checker but I cannot seem to find if
> this is useable anywhere except on Apple OSes.
> For ObjC (and thus @available()) one can still argue that the language isn't
> of much u
Raphael, this test has been failing for a while.
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/9755/console
Testing Time: 466.83s
Failing Tests (1):
lldb-Suite :: expression_command/completion/TestExprCompletion.py
Can you please take a look?
Thanks!
--
David
On Thu, May 31, 2018 at 12:40 PM, Ryan Lovelett via lldb-dev
wrote:
> Well at least there is a little good news. I understood way more of those
> logs than I thought I did.
>
> So two issues here:
> 1 - we need a better error message when vAttachWait returns unsupported
> 2 - fix lldb-server to su
Fred is probably the person who can answer this question
On Tue, May 8, 2018 at 11:06 AM, Zachary Turner wrote:
> +davide, +aprantl for the Apple perspective.
>
>
> On Tue, May 8, 2018 at 10:04 AM Greg Clayton wrote:
>>
>>
>> On May 8, 2018, at 9:47 AM, Zachary Turner wrote:
>>
>> We don’t wa
IIRC We have path normalization functions in llvm, have you looked at them?
Thanks,
--
Davide
On Thu, Apr 19, 2018 at 11:14 AM, Greg Clayton via lldb-dev
wrote:
> We currently have DWARF that has a DW_AT_comp_dir that is set to "./"
> followed by any number of extra '/' characters. I would like
Good day.
While trying to implement a command in lldb I noticed lldb has this
awesome `gui` command that opens an ncurses GUI.
I find it really useful and I wanted to play with it a bit, but I
wasn't really able to get it working.
In particular, I tried to press enter on `target create` or `attach`
7;s failing, but it's probably
> some silly typo. Unfortunately I don't have time to look at it today.
>
> I am hoping that the fix is obvious. If it's not, you can revert that patch,
> and I'll check it out tomorrow.
>
> pl
>
>
> On Tue, 20 Mar
I'm currently bisecting, but this is a FYI (in case it's obvious to anybody)
https://ci.swift.org/job/oss-lldb-incremental-osx-cmake/169/
=
Issue Details
=
FAIL: test_expr_symbols_dsym (expression_command/test/TestExprs2.py)
FAIL: test_expr_symbols_dwarf (expression_comma
On Mon, Mar 19, 2018 at 6:04 PM, Florin Trofin via lldb-dev
wrote:
> Ok,but how do you debug this? Debugging the debugger's formatter seems
> non-trivial. Are there any guides/steps?
>
I generally recommend enabling logs (through `log enable lldb
-f ~/somefile.txt`) and then work back from there
On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham wrote:
> It sounds like we timing out based on the whole test class, not the
> individual tests? If you're worried about test failures not hanging up the
> test suite the you really want to do the latter.
>
> These are all tests that contain 5 or mor
Few examples:
360 out of 617 test suites processed - TestObjCMethods.py
XX
TestObjCMethods.py: 363.726592
381 out of 617 test suites processed - TestHiddenIvars.py
XX
TestHiddenIvars.py: 363.887766
387 out of 61
I'll re-run the test and send you a list.
Thank you!
--
Davide
On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath wrote:
> Aha, in that case, it definitely sounds like increasing the timeout is in
> order. I would still go for something less than 30 minutes, but I don't care
> about that much. I may
On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote:
> I think we should get some data before pulling numbers out of our sleeves.
> If we can get some numbers on the slowest machine that we have around, then
> we should be able to specify the timeout as some multiple of the slowest
> test. For exa
On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham wrote:
> The problem with having no timeouts is that you have to then be fairly
> careful how you write tests. You can't do:
>
> while (1) {
>print("Set a breakpoint here and hit it a few times then stop the test");
> }
>
> because if the breakpoin
On Fri, Mar 9, 2018 at 3:45 AM, Pavel Labath wrote:
>
>
>
> On Thu, 8 Mar 2018 at 18:40, Davide Italiano wrote:
>>
>> On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote:
>> > It would be great to look into these and see what is taking so long.
>> > Some tests are doing way too much work and sho
On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev
wrote:
> I've registered to
> http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent
> my patch via that email to lldb-comm...@lists.llvm.org but doesn't
> appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how l
On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote:
> It would be great to look into these and see what is taking so long. Some
> tests are doing way too much work and should be split up. But it would be
> great to see if we have any tests that are not good tests and are just taking
> too much
Hi,
I've noticed some of the tests we have trigger timeouts when running in debug.
TIMEOUT: test_NSError_p_dwarf (lang/objc/foundation/TestObjCMethods2.py)
TIMEOUT: test_expression_lookups_objc_dwarf
(lang/objc/foundation/TestObjCMethods.py)
TIMEOUT: test_expressions_in_literals_dsym
(lang/objc/ob
On Mon, Feb 26, 2018 at 9:01 PM, Timothee Cour via lldb-dev
wrote:
> https://github.com/llvm-mirror/lldb/pull/3
>
> it would be *really* nice if llvm or lldb accepted industry standard
> github PR's, at least as an option. Would make contributing so much
> easier for outsiders
See the other threa
On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev
wrote:
> I made it work:
> https://github.com/llvm-mirror/lldb/pull/3
> (note: also requires the D plugin on D side which I can submit to
> another repo separately, and which is small)
>
> not sure if lldb accepts github PR's but that's t
On Wed, Feb 7, 2018 at 9:32 AM, Pavel Labath wrote:
> On 6 February 2018 at 15:51, Davide Italiano wrote:
>>
>> FWIW, I strongly believe we should all agree on a configuration to run
>> tests and standardize on that.
>> It's unfortunate that we have two build systems, but there are plans
>> to mo
On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath wrote:
> On 7 February 2018 at 14:20, Zachary Turner wrote:
>>
>> As someone who gave up on trying to set up a bot due to flakiness, I
have a
>> different experience.
>
> I did not say it was easy to get to the present point, and I am
> certain that th
On Tue, Feb 6, 2018 at 8:18 AM, Pavel Labath wrote:
> On 6 February 2018 at 15:41, Davide Italiano wrote:
>> On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote:
>>> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev
>>>
>>> So, I guess my question
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote:
> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev
> wrote:
>> Hi,
>> in the last couple of months a lot of people put a lot of attentions
>> and energy into lldb and we're starting to see the first resu
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote:
> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev
> wrote:
>> Hi,
>> in the last couple of months a lot of people put a lot of attentions
>> and energy into lldb and we're starting to see the first resu
Hi,
in the last couple of months a lot of people put a lot of attentions
and energy into lldb and we're starting to see the first results. I
decided to sit down and write this e-mail to state where we are and
what are some possible future directions for the projects, in terms of
better quality/high
On Thu, Feb 1, 2018 at 6:50 AM, Pavel Labath wrote:
> On 30 January 2018 at 23:21, Davide Italiano wrote:
>> I agree.
>
> Just to check: Does that apply to Tamas's paragraph below, as in
> that's the guidelines we should be giving to new language plugin
> implementors?
>
Yes, that's what I meant
I agree.
I plan to remove the two backends (well, at least submit requests for)
in 3 weeks from today.
There are a lot of moving pieces right now and I'd really love for
things to stabilize but also give people an opportunity to speak up,
if they want to.
--
Davide
On Tue, Jan 30, 2018 at 5:30 AM
On Fri, Jan 26, 2018 at 8:38 AM, Erik Pilkington via lldb-dev
wrote:
>
>
> On 2018-01-25 1:58 PM, Greg Clayton wrote:
>>>
>>> On Jan 25, 2018, at 10:25 AM, Erik Pilkington
>>> wrote:
>>>
>>> Hi,
>>> I'm not at all familiar with LLDB, but I've been doing some work on the
>>> demangler in libcxxabi
Hi,
during my wandering I stumbled upon the `Go` and the `Java` plugins in
the lldb source tree.
They seem to not have been touched in a while, and I'm not necessarily
sure they're in a working state. Keeping them in tree is a maintenance
burden, so unless somebody is actively using them or somebod
On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano wrote:
> On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev
> wrote:
>> Hi lldb-dev!
>>
>> I've been investigating some spurious LLDB test suite failures on
>> http://green.lab.llvm.org/green/ that had to do with build artifacts from
>>
On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev
wrote:
> Hi lldb-dev!
>
> I've been investigating some spurious LLDB test suite failures on
> http://green.lab.llvm.org/green/ that had to do with build artifacts from
> previous runs lying around in the test directories and this promp
On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev
wrote:
> Hi lldb-dev!
>
> I've been investigating some spurious LLDB test suite failures on
> http://green.lab.llvm.org/green/ that had to do with build artifacts from
> previous runs lying around in the test directories and this promp
Jason probably knows about the crash hook.
On Tue, Dec 19, 2017 at 4:24 AM, Pavel Labath wrote:
> On 18 December 2017 at 23:51, Adrian Prantl wrote:
>> I also just hit this and apparently this is an intentional behavior of xcrun.
>>
>> Note that this only affects systems that have the so-called
Pavel, I happened to hit this.
I'm not sure how you worked around, as I tried to export
SDKROOT=macosx but that didn't work for me.
Do you have a patch or a series of commands I can run?
Thanks,
--
Davide
On Thu, Nov 16, 2017 at 4:25 AM, Pavel Labath via lldb-dev
wrote:
> Right, after learning
r316800, thanks!
On Fri, Oct 27, 2017 at 2:07 PM, Zachary Turner wrote:
> One more nitpick. Can you make it a dependency of `check-lldb-lit` target
> also? Just for the sake of pedantry.
>
> On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath wrote:
>>
>> Ship it.
>>
>> On 27 October 2017 at 13:56, D
Take 2 (it can't be in the top-level CMakeList because the check-lldb
target is declared elsewhere).
$ git diff HEAD
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index d5d71d1..958f9f3 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -109,6 +109,12 @@ add_python_test_target(
r, so spitting
> out the executabatle as well should not be too controversial.
>
> On Fri, Oct 27, 2017 at 12:58 PM Davide Italiano via lldb-dev
> wrote:
>>
>> Mind if I try to write a patch for this one or you want to do it?
>>
>> On Fri, Oct 27, 2017 at 12
Mind if I try to write a patch for this one or you want to do it?
On Fri, Oct 27, 2017 at 12:56 PM, Pavel Labath wrote:
> Yes, listing clang as a dependency sounds like a good idea.
>
> On 27 October 2017 at 12:45, Davide Italiano wrote:
>> So, I wiped out my directory for the build and then I c
On Fri, Oct 27, 2017 at 12:52 PM, Ted Woodward
wrote:
> I think if clang exists in-tree, it should be used. If it doesn't, the
> compiler used to build lldb should be used.
>
> Unless, of course, the compiler is specified with the cmake variables.
>
I think that if the default is to run tests wi
So, I wiped out my directory for the build and then I created it again using
cmake -GNinja ../
I found out what the bug/problem is, BTW (was going to reply to this
e-mail but you've beaten me to the punch).
You switched LLDB to build with an in-tree clang, but ninja check-lldb
doesn't really requi
Yes, it seems `configuration.compiler` is None, so this explodes:
[...]
if not is_exe(configuration.compiler):
[...]
On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano wrote:
> I think that this change (or some change nearby) broke `check-lldb` on Fedora.
>
> I'm investigating, but in th
I think that this change (or some change nearby) broke `check-lldb` on Fedora.
I'm investigating, but in the meanwhile, here's the log.
$ ninja check-lldb
[2/2] Testing LLDB (parallel execution, with a separate subprocess per test)
Traceback (most recent call last):
File "/home/davide/work/llvm
On Thu, Feb 16, 2017 at 10:16 PM, Mehdi Amini via llvm-dev
wrote:
> Hello all,
>
> GSOC is around the corner, and the LLVM projects plans to participate again
> this year. For those who don’t know about GSOC, students are proposing a
> project that they will work on for 3 months. Amongst other, on
On Thu, Feb 18, 2016 at 4:22 PM, Hans Wennborg wrote:
> According to the schedule (e.g. on the right on llvm.org), we should
> have tagged the release by now, but we haven't, so we're officially
> behind schedule. I'm still optimistic that we can wrap this up pretty
> soon, though.
>
> This is wha
83 matches
Mail list logo
