Good to see more platforms gaining support. See here:
http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access for details.
From: Deepak Panickal mailto:dee...@codeplay.com>>
Date: Thursday, 10 October, 2013 10:45 AM
To: Greg Clayton mailto:gclay...@apple.com>>, João Matos
mailto:ripzon
Hi all,
I just checked in (r192326) a somewhat useful prototype of a terminal UI that a
few colleagues and I have been working on over the last week or so. It uses
curses through python and drives LLDB directly. The commit message has more
information, but right now there are lots of missing fe
last thing that needs to be committed before I can push the
initial version of the terminal ui we've been hacking on here :)
Cheers,
Dan
On 2013-10-04 10:15 AM, "Malea, Daniel" wrote:
>Yes, originally I had the state-checking logic in WaitForProcessToStop()
>and noticed so
013 7:09 PM
To: Malea, Daniel
Cc: lldb-commits@cs.uiuc.edu
Subject: Re: [Lldb-commits] [PATCH] Make CommandObjectProcess check process
state before calling WaitForProcessToStop
Shouldn't this be done in WaitForProcessToStop?
Jim
On Oct 3, 2013, at 3:34 PM, Malea, Daniel wrote:
> H
Hi all,
I noticed a race condition where a process is launched and hits a breakpoint
while CommandObjectProcessLaunch is still in DoExecute. The effect I'm seeing
is that if Process::WaitForProcessToStop() is called on a stopped process, LLDB
hangs.
This patch fixes the issue by checking the p
a way to invoke lldb commands as well, you would
>need these events.
>
>Jim
>
>
>
>On Oct 3, 2013, at 1:13 PM, Malea, Daniel wrote:
>
>> Hi all,
>>
>> I'm starting to hack on an alternative interface to LLDB, and I noticed
>>the Python SB
3-10-03 4:58 PM, "Mark Lacey" wrote:
>
>On Aug 9, 2013, at 9:09 AM, Malea, Daniel wrote:
>
>> Thanks for the comments Jason; I will leave libdebugserver.cpp in then.
>
>Hi Daniel,
>
>I tried building lldb/debugserver with cmake and there appears to be a
&
Hi all,
I'm starting to hack on an alternative interface to LLDB, and I noticed the
Python SBThread interface is missing the BroadcasterBits enum and the
GetBroadcasterClassName static function.
This tiny patch adds both of those missing things to the SBThread.i interface
file. OK to commit, o
The changes seem reasonable to me too.
A windows buildbot is a fantastic idea!
Dan
-Original Message-
From: lldb-commits-boun...@cs.uiuc.edu
[mailto:lldb-commits-boun...@cs.uiuc.edu] On Behalf Of Greg Clayton
Sent: Friday, September 20, 2013 1:51 PM
To: Virgile Bello
Cc: lldb-commits
Su
Oh, that¹s a neat find; looking forward to the results.
Dan
On 2013-09-17 5:50 PM, "Richard Mitton" wrote:
>For what it's worth, I don't think this is a libedit problem, I believe
>it's a race condition between the newline being flushed though out
>internal libedit pty prompt filter, and the co
Sweet, thanks Greg! It looks like that commit fixes the buildbots.
Dan
On 2013-09-16 6:16 PM, "Greg Clayton" wrote:
>I believe 190811 just fixed this. Please let me know your results!
>
>On Sep 16, 2013, at 12:12 PM, Malea, Daniel
>wrote:
>
>> Hi Greg,
>>
Hi Greg,
This commit seems to introduce a few errors on the buildbots in the following
tests:
- TestDynamicValue
- TestVirtual
http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/6709
When you have a moment, can you take a look?
Thanks,
Dan
-Original Message-
From: lldb-commit
ayton [mailto:gclay...@apple.com]
Sent: Friday, September 13, 2013 7:50 PM
To: reviews+d1682+public+ef3a1a1390e91...@llvm-reviews.chandlerc.com
Cc: Malea, Daniel; lldb-commits
Subject: Re: [Lldb-commits] [PATCH] Improve stability of ProcessMonitor --
use a thread-safe queue instead of file descriptors
first non-inlined function. If that doesn't work we should come
>up with some other heuristic when to give up the comparison and just stop.
>
>Jim
>
>
>On Sep 9, 2013, at 3:33 PM, Malea, Daniel wrote:
>
>> Hi Jim,
>>
>> Thanks again for the feedback.
xes the incorrect logic in the debug case
>by accident, rather than getting the "have debug info" logic correct.
>That doesn't seem like the right fix to me.
>
>I'm in the middle of something right now, so if you can figure out what
>branch of the "have deb
e debug info" logic correct.
>That doesn't seem like the right fix to me.
>
>I'm in the middle of something right now, so if you can figure out what
>branch of the "have debug info part" of this is wrong, that would be
>lovely. Otherwise I'll try to
Hi Ed/Jim,
After this fix, I'm noticing some buildbot failures in
TestInlineStepping.py, which I reproduced locally:
Process 25548 stopped
* thread #1: tid = 25548, 0x00400721 a.out`main(argc=1,
argv=0x7fffd73b7b38) + 33 at calling.cpp:106, name = 'a.out', stop
reason = step over
atch and the one that was there before.
>
>Jim
>
>On Sep 6, 2013, at 2:03 PM, Malea, Daniel wrote:
>
>> Hi Ed/Jim,
>>
>> After this fix, I'm noticing some buildbot failures in
>> TestInlineStepping.py, which I reproduced locally:
>>
>> Proc
Oh, ok. I suppose if people want to use run with arguments that begin with
'-' it would be good to keep the double-dash in the alias.
Thanks for keeping an eye out,
Dan
On 2013-09-05 5:29 PM, "Ed Maste" wrote:
>On 5 September 2013 17:24, Daniel Malea wrote:
>> Author: dmalea
>> Date: Thu Sep
rt. It should not be necessary to have the LLVM
headers around to build programs that only use the lldb SB API's.
Jim
On Sep 4, 2013, at 4:36 PM, Malea, Daniel
mailto:daniel.ma...@intel.com>> wrote:
> This commit introduces a dependency in the LLDB API on the LLVM headers,
> whi
Hi Virgile,
This commit introduces a dependency in the LLDB API on the LLVM headers,
which is not ideal because users of the LLDB API shouldn't be required to
have LLVM headers around IMHO.
Specifically, the api unit tests are now broken on the GCC buildbot.
Here's the include hierarchy that is
Ditto; LLDB should be building against libedit and not readline.
Eric, if you're missing libedit.h (and assuming you're on Ubuntu) you can get
it with:
$ apt-get install libedit-dev
If we have to, we can probably make a build flag to select between the two
implementations..
Dan
From: Richar
s being
>used on a side-project inside Apple that is using libdebugserver.cpp.
>Some day that side-project is going to need to update to our current
>sources and they'll need libdebugserver.cpp to be there.
>
>If nothing else, we can #if 0 the entire file for now.
>
>
>O
Thanks for the comments!
I agree that libdebugserver.cpp looks like dead code. To keep Cmake happy,
it's not sufficient to remove the file from the list of sources; we'd need
to remove it from the directory as well, otherwise the build breaks
because of "unknown source files".
Does anyone have an
Attaching the patch for folks who may not be on Phabricator..
Thanks,
Dan
On 2013-08-08 3:30 PM, "Daniel Malea" wrote:
>
> Hi all, I'm not sure how many people use CMake on Mac OS X.. For those
>who are, this patch gets us a little closer to being able to build
>everything needed for lldb with
Hi Virgile, I looked at the Cmake changes and they seem OK. There don't appear
to be any regressions on Linux with your patch applied..
Dan
From: Virgile Bello mailto:virgile.be...@gmail.com>>
Date: Wednesday, 7 August, 2013 1:01 PM
To: Enrico Granata mailto:egran...@apple.com>>
Cc: "lldb-commit
LGTM, although it would probably be better to use an initializer list for
m_leakand maybe the other members being initialized in that ctor.
Cheers,
Dan
On 2013-08-06, at 5:57 PM, "Michael Sartain" wrote:
> Found by valgrind. m_leak isn't set in IRMemoryMap::Allocation::Allocation().
>
>
check_status doesn't seem to do anything -- is it required?
On 2013-07-24 9:24 AM, "Ashok Thirumurthi"
wrote:
>Author: athirumu
>Date: Wed Jul 24 08:24:06 2013
>New Revision: 187035
>
>URL: http://llvm.org/viewvc/llvm-project?rev=187035&view=rev
>Log:
>Updating tests that fail with ICC 13.1 bec
Hi Ed,
This patch and the one before it seem OK. No regressions detected when
running the test suite with Clang on Linux. Not sure how I would test
loading a FreeBSD core-file on Linux though...
Cheers,
Dan
On 2013-07-22 12:46 PM, "Ed Maste" wrote:
>Choose the type of RegisterContextCore...
29 matches
Mail list logo