tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.
I don't really have an opinion if moving TaskPool to Host is a good or bad idea
(haven't followed the recent layering efforts) but other then that looks good.
I also tested it on Lin
Author: fjricci
Date: Tue Sep 19 08:38:30 2017
New Revision: 313637
URL: http://llvm.org/viewvc/llvm-project?rev=313637&view=rev
Log:
Use ThreadLauncher to launch TaskPool threads
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing
This revision was automatically updated to reflect the committed changes.
Closed by commit rL313637: Use ThreadLauncher to launch TaskPool threads
(authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D37930?vs=115691&id=115844#toc
Repository:
rL LLVM
https://reviews.llvm
Author: fjricci
Date: Tue Sep 19 10:13:39 2017
New Revision: 313642
URL: http://llvm.org/viewvc/llvm-project?rev=313642&view=rev
Log:
Fix build of TaskPoolTest with xcodebuild
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http:/
lemo added a comment.
Ping? Are there any more open questions or unresolved comments or is this good
to be checked in?
Thanks!
https://reviews.llvm.org/D37923
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/
clayborg added a comment.
We should have a test. The test would need to use pexpect or something similar.
If anyone has any pointer on how to make a test for this, please chime in. I
was thinking just a pexpect based test.
https://reviews.llvm.org/D37923
zturner added a comment.
Give me a few more hours, if there's a way to make this work with
`line_iterator` I'd really prefer that since I think it improves readability.
Can you confirm that if you were able to write:
auto begin = line_iterator(str, /* skip_empty_lines =*/ false);
auto end
zturner added a comment.
In https://reviews.llvm.org/D37923#875322, @clayborg wrote:
> We should have a test. The test would need to use pexpect or something
> similar. If anyone has any pointer on how to make a test for this, please
> chime in. I was thinking just a pexpect based test.
This
Python based commands will need to be able to call WasInterrupted if they are
going to do their jobs. So it would make sense to add an
SBCommandInterpreter::WasInterrupted API and make sure that works. And you can
already send the interrupt with DispatchInputInterrupt. So it should be pretty
I'd really prefer to do this as/along with an SB API test since we also need
commands made through the SB API to be interruptible, and we should test that
that also works. So this kills two birds with one stone.
In general, when developing any high-level features in lldb one of the
questions y
Author: amccarth
Date: Tue Sep 19 11:07:33 2017
New Revision: 313655
URL: http://llvm.org/viewvc/llvm-project?rev=313655&view=rev
Log:
Re-land r313210 - Fix for bug 34532 - A few rough corners related to
post-mortem debugging (core/minidump)
The main change is to avoid setting the process state
That would work, but I think it's adding many more pieces to the test. Now
there's threads, a Python layer, and multiprocess dotest infrastructure in
the equation. Each providing an additional source of flakiness and
instability.
If all it is is a pass-through, then just calling the function it
Also, it avoids polluting the SB interface with another function that
probably nobody is ever going to use outside of testing. Adding to the SB
API should take an act of God, given that once it gets added it has to stay
until the end of time.
On Tue, Sep 19, 2017 at 11:15 AM Zachary Turner wrote
I disagree. The things we care about are (a) that this works in C++
implemented commands and (b) that it works in Python commands. This doesn't
seem to test either of those things.
Also, I find writing tests for new functionality to be a great way to inform
you about what you need to add to t
These are all great suggestions, thanks everyone!
> We should have a test. The test would need to use pexpect or something
similar. If anyone has any pointer on how to make a test for this, please
chime in. I was thinking just a pexpect based test.
I love tests but what exactly do we want to test
We agreed to forwards compatibility because people write big scripts that use
the SB API, implement GUI's on top of them (more than just Xcode) etc. So we
try not to jerk those folks around. That adds a little more responsibility on
our part to think carefully about what we add, but the notion
This looks beautiful indeed. The problem is that it doesn't quite work with
the current MemoryBuffer and the line_iterator : for one thing there's no
way to construct a MemoryBuffer from a StringRef, or to use the
line_iterator directly with a StringRef.
On Tue, Sep 19, 2017 at 10:39 AM, Zachary
Right, I can fix that. Give me a few minutes though.
On Tue, Sep 19, 2017 at 11:28 AM Leonard Mosescu wrote:
> This looks beautiful indeed. The problem is that it doesn't quite work
> with the current MemoryBuffer and the line_iterator : for one thing there's
> no way to construct a MemoryBuffe
On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham wrote:
> We agreed to forwards compatibility because people write big scripts that
> use the SB API, implement GUI's on top of them (more than just Xcode) etc.
> So we try not to jerk those folks around. That adds a little more
> responsibility on our
> On Sep 19, 2017, at 11:30 AM, Zachary Turner wrote:
>
>
>
> On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham wrote:
> We agreed to forwards compatibility because people write big scripts that use
> the SB API, implement GUI's on top of them (more than just Xcode) etc. So we
> try not to jerk
I agree Jim. I'd like like to build thing incrementally - checking in the
current change as is does not preclude adding the SB APIs while it does
provide the foundation.
I think that going after the scenarios you mention is a significant
increase in scope. Are people even hooking up DispatchInterr
IIRC Enrico put in something where we would tell Python to interrupt at points
where Python checks for interruptibility, but that is pretty herky-jerky. It
would be much better to have the commands control this.
Jim
> On Sep 19, 2017, at 11:34 AM, Jim Ingham wrote:
>
>
>> On Sep 19, 2017, a
Xcode does, I don't know about other UI's.
Jim
> On Sep 19, 2017, at 11:35 AM, Leonard Mosescu wrote:
>
> I agree Jim. I'd like like to build thing incrementally - checking in the
> current change as is does not preclude adding the SB APIs while it does
> provide the foundation.
>
> I think
On Tue, Sep 19, 2017 at 11:34 AM Jim Ingham wrote:
>
> > On Sep 19, 2017, at 11:30 AM, Zachary Turner wrote:
> >
> >
> >
> > On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham wrote:
> > We agreed to forwards compatibility because people write big scripts
> that use the SB API, implement GUI's on top
So, how about I look into exposing WasInterrupted() through SB APIs in a
follow up change?
On Tue, Sep 19, 2017 at 11:36 AM, Jim Ingham wrote:
> Xcode does, I don't know about other UI's.
>
> Jim
>
> > On Sep 19, 2017, at 11:35 AM, Leonard Mosescu
> wrote:
> >
> > I agree Jim. I'd like like to
I must be missing something.
DisaptchInputInterrupt knows how to interrupt a running process, and because of
Enrico's Python interruption stuff it will interrupt script execution at some
point but it wasn't very reliable last time I tried it.
But the whole point of this patch is that in gen
That seems fine to me.
Jim
> On Sep 19, 2017, at 11:39 AM, Leonard Mosescu wrote:
>
> So, how about I look into exposing WasInterrupted() through SB APIs in a
> follow up change?
>
> On Tue, Sep 19, 2017 at 11:36 AM, Jim Ingham wrote:
> Xcode does, I don't know about other UI's.
>
> Jim
>
On Tue, Sep 19, 2017 at 11:40 AM Jim Ingham wrote:
> I must be missing something.
>
> DisaptchInputInterrupt knows how to interrupt a running process, and
> because of Enrico's Python interruption stuff it will interrupt script
> execution at some point but it wasn't very reliable last time I tri
> On Sep 19, 2017, at 11:25 AM, Leonard Mosescu wrote:
>
> These are all great suggestions, thanks everyone!
>
> > We should have a test. The test would need to use pexpect or something
> > similar. If anyone has any pointer on how to make a test for this, please
> > chime in. I was thinking
Thanks for the context.
On Tue, Sep 19, 2017 at 11:58 AM, Jim Ingham wrote:
>
> > On Sep 19, 2017, at 11:25 AM, Leonard Mosescu
> wrote:
> >
> > These are all great suggestions, thanks everyone!
> >
> > > We should have a test. The test would need to use pexpect or something
> similar. If anyon
Any pointers on the steps required to make changes to the SB APIs? Is it
documented anywhere? Thanks!
On Tue, Sep 19, 2017 at 11:58 AM, Jim Ingham wrote:
>
> > On Sep 19, 2017, at 11:25 AM, Leonard Mosescu
> wrote:
> >
> > These are all great suggestions, thanks everyone!
> >
> > > We should ha
Here's a short description of the coding rules and the general idea of how to
add API's:
http://lldb.llvm.org/SB-api-coding-rules.html
If you come across something you wished would have been in this document while
you are implementing this, please add it. It's sometimes hard to see some
cruci
Author: eugene
Date: Tue Sep 19 17:39:04 2017
New Revision: 313704
URL: http://llvm.org/viewvc/llvm-project?rev=313704&view=rev
Log:
Signal polling is supported with pselect
Older Android API levels don't have ppoll, but LLDB works just fine,
since on Android it always uses pselect anyway.
Modif
On Tue, Sep 19, 2017 at 11:51 AM Zachary Turner wrote:
> On Tue, Sep 19, 2017 at 11:40 AM Jim Ingham wrote:
>
>> I must be missing something.
>>
>> DisaptchInputInterrupt knows how to interrupt a running process, and
>> because of Enrico's Python interruption stuff it will interrupt script
>> ex
Author: eugene
Date: Tue Sep 19 18:57:59 2017
New Revision: 313707
URL: http://llvm.org/viewvc/llvm-project?rev=313707&view=rev
Log:
Rollback r313704 because of the Windows build break
Modified:
lldb/trunk/include/lldb/Host/MainLoop.h
lldb/trunk/source/Host/common/MainLoop.cpp
Modified:
> On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits
> wrote:
>
>
>
> After some additional thought, I stilled think testing below the sb api layer
> is more appropriate.
> While Xcode might be going through the SB api, users of upstream lldb
> (which is what we supposed to be
Author: eugene
Date: Tue Sep 19 23:56:46 2017
New Revision: 313726
URL: http://llvm.org/viewvc/llvm-project?rev=313726&view=rev
Log:
Signal polling is supported with pselect (re-land r313704 without a Windows
breakage)
Older Android API levels don't have ppoll, but LLDB works just fine,
since on
37 matches
Mail list logo
