I have a patch locally that renames lldb_private::Error to
lldb_private::LLDBError. As you might expect, this is a pretty large patch
so I don't plan to put it up for review, but since it's kind of a
fundamental class I figured I should at least start a discussion.
The primary motivation for this
> On Apr 28, 2017, at 4:04 PM, Pavel Labath wrote:
>
> MainLoop was meant to be a general event multiplexer. One of those
> events can certainly be "a certain amount of time expiring".
> So, you could write something like:
> loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() });
> wh
MainLoop was meant to be a general event multiplexer. One of those
events can certainly be "a certain amount of time expiring".
So, you could write something like:
loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() });
which would translate to an appropriate timeout argument to ppoll.
I think in the common case of listening for a remote connection infinite (or
very very long) timeout with signal interrupt is the preferred approach. There
are other situations where we use SelectHelper with smaller timeouts, and I
think ultimately we should replace SelectHelper with MainLoop be
(1) is okay, except pretty much every time so far I've ever said "operation X
can't possibly take more than N seconds" somebody finds a case in which that
assumption was wrong. So you end up having to make the timeouts so long they
look like stalls anyway... An explicit cancellation gesture is
Hi,
I am having a problem building the 4.0 release branch of LLDB on Debian
Stretch. Cmake returns the following fault:
-- LLDB version: 4.0.0
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.4")
-- Performing Test HAVE_PROCESS_VM_READV
-- Performing Test HAV
Ultimately I think the solution here is two changes
(1) We should add a timeout to MainLoop so that it doesn't wait forever unless
we really want to wait forever.
(2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
kevent, so we should probably set that up too.
-Chris
Seems to me a better UI would be to make ^C interrupt this wait. That seems to
me better than putting in some arbitrary timeout.
Jim
> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
> wrote:
>
> Hi Chris, Pavel,
>
> I've got a problem launching the hexagon simulator from lldb. It's
Hi Chris, Pavel,
I've got a problem launching the hexagon simulator from lldb. It's launched
the same way that debugserver/lldb-server is launched, with reverse connect
on a TCP socket. The user can modify the simulator command line (using
target.run-args), and can easily give a set of options tha
Hmmm ok, I don't like hard coding pools. Your idea about limiting the
number of high level threads gave me an idea:
1. System has one high level TaskPool.
2. TaskPools have up to one child and one parent (the parent for the high
level TaskPool = nullptr).
3. When a worker starts up for a given Ta
Hello all,
I'd like to submit D32434 soon, which adds a dependency on yaml2obj,
which I use to test elf file parsing code. This will break the xcode
build as it does not provide path to the yaml2obj binary to the unit
tests.
As far as I can tell, fixing the build should be easy and amounts to
add
On 27 April 2017 at 00:12, Scott Smith via lldb-dev
wrote:
> After a dealing with a bunch of microoptimizations, I'm back to
> parallelizing loading of shared modules. My naive approach was to just
> create a new thread per shared library. I have a feeling some users may not
> like that; I think
On 27 April 2017 at 19:12, Jim Ingham wrote:
> Interesting. Do you have to catch this information as the JIT modules get
> loaded, or can you recover the data after-the-fact? For most uses, I don't
> think you need to track JIT modules as they are loaded, but it would be good
> enough to refr
Indeed, master restart is needed every time you update the zorg repository.
cheers,
pl
On 28 April 2017 at 03:40, Kamil Rytarowski wrote:
> On 24.04.2017 11:42, Pavel Labath wrote:
>>
>>
>> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>
>>
14 matches
Mail list logo
