It's going to be quite difficult for lldb to do anything reasonable with the
core file if we can't seek around in it. So for practical purposes it is going
to have to get stored somehow, either in a file or in some memory that lldb can
do random access on. So practically whoever is getting thi
lldb has "target stop-hook"s that you can use to add LLDB command-line commands
to react to any sort of stop. The intent is to also allow Python stop hooks,
then you could switch on the thread's stop reason and do signal specific stuff
for a signal stop. But nobody has gotten around to adding
The server is sending back code. I'd want to know I can trust whoever is
sending me back code that I plan to build and run locally.
Jim
> On Nov 19, 2015, at 11:40 AM, Zachary Turner via lldb-dev
> wrote:
>
>
>
> On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote:
> Some other points we ne
> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie
> wrote:
>
> Sorry for the delay, I revisited the issue today.
>
> It is causing a problem for our architecture which does not support single
> instruction stepping. We emulate it with breakpoints and a processor
> exception on branch taken.
>
k the
same to the higher layers of the debugger.
Jim
> On Nov 30, 2015, at 5:24 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie
>> wrote:
>>
>> Sorry for the delay, I revisited the issue today.
>>
>
> On Dec 2, 2015, at 8:35 AM, Todd Fiala via lldb-dev
> wrote:
>
> Does our init file mechanism have the ability to do something conditionally
> if it's a core file? (i.e. do we already have a way to get Ted's desired
> behavior via an inserted call to "thread backtrace all" that somehow get
Todd is right, at runtime lldb does need to find some of the clang include
files in order to build modules for its own purposes. On an OS X install,
these headers are put in:
LLDB.framework/Resources/Clang
and are:
> ls
./ avx512vlbwintrin.h lzcntintrin.h
Should we change the name of lldb/packages/Python/lldbsuite/dotest.py to
something else to avoid this confusion?
Jim
> On Dec 2, 2015, at 2:48 PM, Zachary Turner via lldb-dev
> wrote:
>
> You shouldn't have to point it anywhere. Just run lldb/test/dotest.py the
> same way you're currently r
On OS X Ctrl left & right arrow are taken over by the system to move between
virtual desktops. Instead, option left & right are the equivalent gesture for
move by word on OS X, and in the OS X lldb, option left & right do indeed move
by word.
LLDB doesn't do most of this stuff by hand, it lets
There is currently no API to access the settings. You have to cons up commands
and use SBCommandInterpreter::HandleCommand to execute them.
This is one of the remaining holes in the SB API.
Jim
> On Jan 14, 2016, at 2:41 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> We are building an
On Jan 15, 2016, at 11:28 AM, Greg Clayton wrote:
>
> That being said, feel free to add something the SB API and propose a patch.
>
> Greg
>
>> On Jan 14, 2016, at 3:13 PM, Jim Ingham via lldb-dev
>> wrote:
>>
>> There is currently no API to access the setti
> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev
> wrote:
>
> +lldb-dev
>
> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov wrote:
> Thanks, that was it!
>
> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath wrote:
> Hi,
>
> The stopped event should have the "restarted" flag set. You
Please do file a bug, that's definitely not how things are supposed to work.
You will still see a private "running" event, of course, since those are just
the raw events from the target, but the running event shouldn't get broadcast
to the public event queue if it was coming from a continuation
There is no requirement that the lldb API’s be called on a particular thread on
OS X. LLDB tries to be robust against being called from multiple threads
simultaneously for the same debugger, but you can still make it fall over if
you try hard, particularly if you allow multiple threads to resta
I can’t comment on Windows, I don’t know what requirements the Windows API’s
place on the debugger.
Its been a while since I’ve worked on Linux, but I don’t remember anything that
would privilege one thread over another.
lldb supports running multiple targets and processes in one debugger, an
I don’t think we can change this behavior, since other clients are relying on
the way it is now.
In any case, attach won't return till it is successful, and presumably you know
you are attaching, so I don’t think there’s any ambiguity about what is going
on, even if you don’t get a stop event.
It’s unclear to me why it would be a problem to listen to every thread object?
They aren’t terribly chatty or anything, and you can listen to all of them with
one listener.
Note, you don’t have to sign up individually for every thread object’s
broadcaster. That would be really annoying. In l
Often when attaching, you know the executable you are planning to attach to.
So the "normal" workflow is to create a target, then attach to the process with
that target's executable. This is particularly useful for remote debugging,
since having a local copy of the binary will mean less data l
In synchronous mode, you should never see events. The part of lldb that is
making the command synchronous is using those events to make the command wait
till the action it initiated completes before it returns. If it is letting
process control events leak out, then that is a bug.
If you are r
I don't know what:
event_thread = LLDBListenerThread(debugger)
does, but from your little sketch it looks like you are starting up a thread
listening on this debugger, and so far as I can see you destroy the debugger
out from under it without ever closing down that thread. That doesn't see
You should ask on a clang list for a 100% correct answer, but I am pretty sure
clang does not support macro information. You can get somewhat the same result
by building clang modules and importing them into lldb. But you can't build
modules for C++ yet, so you can only do this for C & ObjC pr
The broadcasters and listeners depend mutually on one another. The listener
keeps a list of the broadcasters it is listening to, and the broadcaster a list
of the listeners it is broadcasting to. When the broadcaster goes down it
removes the listeners from its list and ditto for the listeners
The Python API is pretty much a mirror of the C++ API's. The process_events.py
example:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
should give you a sense of how the broadcasters & listeners are used.
Translating that from Python to C++ is quite straightforw
If the linux side is not obeying "stop_at_entry" then that is a bug.
Jim
> On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> I have got lldb launch working fine on my macbook for sometime. But when I
> try the same code on Linux, it failed to emit any stopping event
That also is a bug. If it is going to do a public stop, it has to send a stop
event.
Jim
> On Feb 23, 2016, at 2:52 PM, Jeffrey Tan wrote:
>
> I am not sure. From the output, it seems lldb does stop at the entry
> point(because you can issue "bt" command to dump the stack) in both
> platfor
Yes, the process listener is a little bit special.
When you are running a process in the debugger, the process is likely going to
be stopping and starting for all sorts of reasons. For instance, stepping
through a source line is actually going to:
step over the breakpoint at the start pc - i
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and display them
> in output UI so that debugger users can have a basic clue what is debugger
> busy doing while launching a big executable linking many sha
There isn’t necessarily A load address for an SBModule. After all, the
different segments could load with different offsets. We usually list the
offset of the __TEXT__ address as the load address - for instance in “image
list", since if you are only interested in symbolication, that’s what you
I'm surprised that this turns out to be a bottleneck. All the work to create
the threads should have been done when you stopped, so this should just be
running over a vector that already exists and pulling a field out. Can you
profile this and see what is actually slow?
Jim
> On Mar 3, 2016,
> On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> My colleague is trying to use our lldb IDE attaching to app run/build from
> Xcode which failed. I can reproduce this with lldb console:
>
> jeffreytan-mbp:$ ps aux | grep iOSApp
> jeffreytan 61816 0.0 0.0 2
lldb uses DWARF expressions internally as a convenient language to represent
locations of values. We had to pick some representation, and the DWARF
expression was powerful enough for our purposes, meant we didn't have to
reinvent something that already existed, and had the added benefit that if
You only show one thread in your example. Did another thread have a valid stop
reason? lldb shouldn’t be stopping for no reason anywhere…
Jim
> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Btw: the breakpoint I set is:
> "b BigGrepMasterAsync.cpp:171" which is not in a
Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you are on
a platform whose primary compiler is gcc and that isn’t very very old, either
demangler will be equivalent except for bugs. The side effects of one or the
other are pretty much just that you get a different set of bu
The selected thread should be getting set. You didn’t include the code for
_send_paused_notification so I don’t know what that does, but if
SBProcess::GetSelectedThread wasn’t returning a thread with a valid stop
reason, then there’s some bug somewhere. That’s all done in generic code,
howeve
The driver used to have a bunch of lldb_private stuff in it, mostly to run the
event loop, which Greg abstracted into SB API’s a while ago. If it can be
avoided, I’d rather not add it back in. Our claim is folks should be able to
write their own debugger interfaces (command line or gui) using
If I were writing a Pure Python interface to lldb, could I use the Python
signal facilities to abstract the functionality you are trying to abstract
through Host::Signal? If so, then I’d have no objection to only doing it in
the C++ API’s (maybe with a note to that effect in the headers.)
If n
Please file bugs where the lldb implementation of the MI doesn't support
features documented in the GDB MI documentation.
Jim
> On Mar 16, 2016, at 11:01 AM, RISHABH GUPTA via lldb-dev
> wrote:
>
> 2.-var-update command ,In GDB/MI "-var-update *" works fine but the same
> command in LLDB/MI
On many platforms (OS X for sure) there’s no guarantee that when you stop you
will only have hit one breakpoint on one thread. On OS X in multithreaded
programs, it is not at all uncommon to have many threads hit breakpoint(s) by
the the time the stop gets reported. So you just have to iterate
The code that has gotten itself into an infinite loop here is the libiberty
cp-demangle.c, which is part of the C++ runtime libraries for the system you
are on. So we can't do anything to fix bugs with that. You might make sure
there isn't a newer version of that than the one on your system, b
All this logic is handled in Process::HandleProcessStateChangedEvent (see
around line 1215 in Process.cpp) You shouldn’t have to reimplement the logic
for setting the selected thread unless you don’t like our heuristics. Note,
that’s in generic code, so I don’t know why it wouldn’t be working
What version of the lldb sources are you working with? I changed the
SBListener over to using only the ListenerSP internally
in r262863.
Jim
> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev
> wrote:
>
> Hey,
>
> I am currently working on lldb bindings for javascript (v8) but it
> seems
I vaguely remember that not all Unixen support detaching from a process that is
a child of the debugger that is attached to it. If you run the process under
gdb & detach, does the process survive? This may not be an exact test, since
gdb may use procfs rather than ptrace, I don't know any more
lldb doesn't currently work if you leave the process of cleaning up to the C++
destructor chain. You need to call Debugger::Destroy on your way out.
I think there's a bunch more cleanup than just the broadcaster/listener stuff
before we'll do this right.
Jim
> On Mar 28, 2016, at 8:55 AM, P
Yes, that should work too. The thing that doesn't work is to just let the C++
destructor chain tear down the debuggers you've made. It should be possible to
make that work, but nobody's had time to make that happen, and given you can
avoid the crashes if you exit cleanly, it hasn't been a terr
The exception breakpoints Greg is talking about are language exceptions (C++
throws, Swift Errors and the like.)
I don't know what kind of exception you are talking about here, but at least
from a command interface standpoint, it would be good to keep alike things that
actually are alike, but o
Interesting.
For the other windows exceptions, could we do something abstract like:
(lldb) break set --platform
(-P for short) to set a "platform breakpoint", where "data" is a string that
the current platform will understand, but the breakpoint machinery doesn't have
to.
The way breakpoin
Yes, that's why I prefer a more abstract command interface than trying to be
too specific about some abstract breakpoint. So you'd just have:
Error
Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char *data);
Then this can have any meaning that it needs to. The other way to
> On Apr 4, 2016, at 11:48 AM, Carlo Kok wrote:
>
>
>
> Op 2016-04-04 om 20:41 schreef Greg Clayton:
>>
>>> On Apr 4, 2016, at 11:36 AM, Carlo Kok wrote:
>
>>>
>>> There should be a way then to do a "break on every exception", instead of
>>> just 1 specific code.
>>
>> That would b
If we're going this far, then we should just add a "catch" command, and have
the platforms be able to add "catchable" things. For instance, you could catch
shared library loads, you could catch fork & exec, maybe IPC message sends and
Windows exceptions. Seems like they fit better in this mode
"catch" would be for stopping on any process life-cycle events that aren't
watchpoints or breakpoints (thread creation, spawning, etc are other examples.)
That seems quite well-defined to me. And I like that the ways you can stop a
program are not scattered throughout the command set. By putt
I don't think Enrico was suggesting that we maintain a bunch of third party
data formatters in the lldb source base. He was giving C++ examples (using the
lldb_private API's) because the STL formatters are in C++, so that's what he
had on hand to demonstrate the kinds of algorithms you would us
> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
> wrote:
>
> I’m stepping over the first line of a libcxx test (source
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
> ). The first line has an inlined function
Why are we remapping the FileSpecs in SymbolContext's we are handing out? That
seems to me a bad idea. It means that every time I want to do a FileSpec
compare between the LineEntry FileSpec's that I get at from stack frames at two
different times, I have to remember to re-apply the SourceMap
requirement clearer.
Jim
> On May 6, 2016, at 3:49 PM, Jim Ingham via lldb-dev
> wrote:
>
> Why are we remapping the FileSpecs in SymbolContext's we are handing out?
> That seems to me a bad idea. It means that every time I want to do a
> FileSpec compare between the
ll
> the Debugger's, and the Debuggers could have different SourceMaps. So by
> putting this explicitly in the LineEntry - which is not something we use to
> store line information, it's just something we cons up to hand out when
> requested - it might make that requirement c
o remap FileSpecs that are
>> in the module's debug information, since these modules are shared among all
>> the Debugger's, and the Debuggers could have different SourceMaps. So by
>> putting this explicitly in the LineEntry - which is not something we use to
You should be able to enumerate the memory that is occupied by loaded
executables, by getting the list of loaded Modules from the target, and iterate
through the all the Sections. The Sections know their loaded locations. I
assume all the mapped ones will return a valid load address from
GetL
Oh, that's a cute trick, but it relies on the not (at-least-to-me) obvious fact
that an address in an unmapped region will return the extents of the unmapped
region. For it to be useful, that needs to be a requirement of the API's
implementation.
It seems to me it would be much clearer to have
Provided it builds everywhere and you are planning on continuing to work on it,
I see no problems with putting this into the lldb tree. If there are any parts
that touch common code, you might want to submit those first (in appropriate
chunks) so that the people who are going to review it can se
as to
> allow different implementations when one os/architecture has a better way of
> doing it.
This would fall out naturally if the gathering of the data is done in
debugserver/lldb-server, which seems to me the natural place for this work to
be done.
Jim
>
> On Thu, May 12, 2016
> On Jun 3, 2016, at 2:22 AM, Abhishek Aggarwal via lldb-dev
> wrote:
>
> Hi everyone
>
> While debugging an inferior with LLDB, for every stop event a new StopID is
> generated and this ID can be extracted from SBProcess::GetStopID() API. This
> ID indicates change in the state of the proce
Note that we do know when we've actively suspended threads, but in an average
step, you will spend a fair bit of the time allowing all threads to run. So
that wouldn't allow a very accurate accounting.
Jim
> On Jun 3, 2016, at 8:42 AM, Jim Ingham via lldb-dev
> wrote:
&
We have a not-yet-implemented scheme to allow some syntax like:
(lldb) expr $$foo.c$bar(5)
that would mean: look up the version of bar defined in foo.c and call that.
What I wrote above isn't right, since the "." is going to cause the parser
headaches, so we'll have to come up with some clever
Note this isn't something we made up... In the gdb remote protocol spec, it
says:
The error response returned for some packets includes a two character error
number. That number is not well defined.
I think they are just meant to be useful for debugging a particular gdb-remote
protocol server
Your guess about the use of the checkers is right. The code you are looking at
compiles and inserts this function in the target, then when compiling future
expressions, if we detect a reference to an ObjC object, we insert a call to
the checker into the JIT'ed code before accessing the object.
Nothing of this sort has been done to my knowledge, and I haven't heard of any
plans to do so either.
It should certainly be possible, you just need to grub the C stack and
recognize the pattern of a Python stack frame in it and where said frame
stashes away the arguments & locals, and then re-
gdb used to try to find a symbol matching the breakpoint specification and if
it didn't find one immediately, it would raise an error. If you didn't want
this behavior (in a world with many shared libraries you seldom did) then you
could set a "future-break" which is what the -f flag turns on.
That is my understanding of what the -f flag is supposed to do. It doesn't
take an argument, it just directs gdb to do "future-break" rather than "break".
The lldb MI should probably just parse & discard it.
Jim
> On Jul 11, 2016, at 1:59 PM, Pierson Lee (PIE)
> wrote:
>
> So the instance
JumpToLine just resets the PC, it doesn't continue the process. For an API, it
makes more sense to let the API user decide whether they want to do more work
before continuing. So you wouldn't expect a "running" event.
We could send a PC-changed event, but we generally only send that sort of ev
> On Jul 20, 2016, at 4:32 PM, Khaled Mohammed via lldb-dev
> wrote:
>
> Hi,
>
> Is there a document which describes in detail how the expression evaluation
> works? is there a wiki for lldb developers?
>
There is no documentation beyond the code & its comments describing how this is
done,
The finish breakpoint is an interesting notion, file a pr & I'll add it when I
have some time.
A while back I added the ability to make "stepping" operations that are
scripted. Seemed to me that could be used for this purpose, but it turns out I
needed a couple more things to make it work, whi
Shouldn't this be made general and added to the llvm coding conventions? I was
assuming that upon completion of this exercise, we would delete the lldb coding
conventions doc.
Jim
> On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev
> wrote:
>
> On Wed, Aug 10, 2016 at 10:37 PM Chris
> On Aug 11, 2016, at 12:19 PM, Ted Woodward
> wrote:
>
> I don’t think we can completely get rid of the lldb coding conventions doc;
> we’ll need this type of thing as long as we use swig:
>
> · enumerations that might end up being in the lldb SB API's should all be
> written like:
>
>
> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> wrote:
>> I recommend approaching this in three steps:
>>
>> 1) get the less-controversial changes done that Greg was outlining.
>> 2) start a discussion in the llvm
Are you sure the actual handling of the breakpoint & callback in lldb is what
is taking most of the time? The last time we looked at this, the majority of
the work was in communicating with debugserver to get the stop notification and
restart. Note, besides all the packet code, this involves c
> On Aug 16, 2016, at 10:42 AM, Benjamin Dicken
> wrote:
>
> Thanks for the quick reply.
>
> > Are you sure the actual handling of the breakpoint & callback in lldb is
> > what is taking most of the time?
>
> I'm not positive. I did collect some callgrind profiles to take a look at
> where
We've talked about providing a more natural view of registers that are
logically made of subfields, as you describe, but I don't think any work has
been done on that front.
The ValueObjectRegister has a couple of ways to implement this display. The
ValueObjectRegisters can be given a type, and
> On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev
> wrote:
>
> The thing is, the code is already full of data races. I think the
> std::atomic is actually used incorrectly and is not even doing anything.
>
> That said, consider darwin on 32-bit, where I believe each stack frame is
> On Aug 26, 2016, at 11:44 AM, Adrian McCarthy via lldb-dev
> wrote:
>
> Methods like Address::SetOffset and Address::Slide seem to have data races
> despite m_offset being atomic. Callers of those methods would have to
> guarantee that nothing else is trying to write to m_offset. And if t
That seems to me a compiler bug, not: "You can't pass structures with
std::atomic" elements in them by value. It would crazy to add a type to the
C++ language that you couldn't use everywhere. There doesn't seem to be any
official restriction. And anecdotally there's a reference to the proble
That is the demangler crashing on some C++ name in your program.
We added a "demangle" log channel to the lldb for Xcode 8.0 (it's also in TOT
lldb) to make debugging this sort of crash easier. Put:
log enable -f /tmp/lldb-demangle-log.txt lldb demangle
in your ~/.lldbinit file, then run your
The "dsymForUUID" tool doesn't handle copying source files around - we tend to
just remote mount them. But we do include these keys in the return plist so
that lldb can automatically remap the source files from where they were at
build time to where they are at debug time. So if your symbol se
"unresolved" means that we know what address we want to set a breakpoint at,
but for some reason can't. For instance, if you were using -H and ran out of
hardware breakpoints, then the subsequent breakpoints would never get resolved,
since we can't implement them.
Anyway, going from unresolved
The addresses for the two breakpoints are reported differently in your "break
list" output. The successful one is given as:
0x00013488
but the one that isn't sent is still given as:
MipsTest.bin[0x000134a0]
That's a file offset address, not a load address. It sounds like we don't know
where
> On Sep 1, 2016, at 2:01 AM, René J.V. Bertin via lldb-dev
> wrote:
>
> Hi,
>
> MacPorts has long had ports for llvm and clang which are very practical.
> Ports for lldb have been missing until now, so I've been trying to create one
> based on the existing clang port. That wasn't particular
The main problem with the watchpoint code is that it doesn't share nearly as
much of the implementation of options and callback handling with the
breakpoints as it should. For instance, there's very little need for
WatchpointOptions and BreakpointOptions to be separate classes, they do pretty
> On Sep 9, 2016, at 7:33 PM, Daniel Noland wrote:
>
> Yes, that was pretty much my assessment when I read through the code.
>
> My existing patch (which I will post when I get home) takes a very
> conservative approach and only modifies what is strictly necessary to make
> the callback featu
> On Sep 12, 2016, at 11:53 AM, Daniel Noland wrote:
>
>
>
> On 09/12/2016 11:30 AM, Jim Ingham wrote:
>>
>>> On Sep 9, 2016, at 7:33 PM, Daniel Noland wrote:
>>>
>>> Yes, that was pretty much my assessment when I read through the code.
>>>
>>> My existing patch (which I will post when I g
Yes, the "script" command always sets up the lldb.{process/thread/frame}
regardless of whether its input is one-line or from the Script Input reader.
The help for script should specify that.
Jim
> On Sep 14, 2016, at 10:24 PM, Lei Kong via lldb-dev
> wrote:
>
> Does the following qualify as
You passed an error into ReadPointerFromMemory. In the cases where you aren't
getting what you expect, what does that error say?
Jim
> On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev
> wrote:
>
> I ran into the error in the subject when running a python script with "script
> myfile.myscr
> On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev
> wrote:
>
>
>
> On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote:
>
> > • Separate testing tools
> > • One question that remains open is how to represent
> > the complicated needs of a debugge
> On Sep 19, 2016, at 3:19 PM, Zachary Turner wrote:
>
> Obviously I defer to you on whether testing via the SB API is better than
> what GDB does or used to do. But these are not the only two systems in the
> world. Having used both LLDB and LLVM's test suite extensively, I still
> remain
> On Sep 19, 2016, at 3:32 PM, Zachary Turner wrote:
>
> Ok, in that case I agree with you more. We should test the scripting
> interface. It's part of the software, it should be treated as such. 100% on
> board. But if we find that it is lacking (or even just inconvenient) to test
> the
evant now
that we've got a working debugger and a pretty well designed public API.
Jim
> On Sep 19, 2016, at 3:49 PM, Jim Ingham via lldb-dev
> wrote:
>
>>
>> On Sep 19, 2016, at 3:32 PM, Zachary Turner wrote:
>>
>> Ok, in that case I agree with you more
If you use the MI, that assumes that the server process is the one doing most
of the work. lldb is not meant to be a light-weight program, and if you start
feeding it a lot of symbol information you may find it taking up too many
resources to really want to run it on your device. For device d
> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
> wrote:
>
> I have been giving study to the private and public classes for
> break/watchpoints and I have some ideas for how to improve them. I am
> looking for comments from the community on this now to avoid wasted work and
> On Sep 27, 2016, at 2:23 PM, Zachary Turner via lldb-dev
> wrote:
>
>
>
>
> On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 4. All of these classes are "old school" (not necessarily bad, but
> potentially a problem). For examp
> On Sep 27, 2016, at 2:55 PM, Daniel Austin Noland
> wrote:
>
>>> The main problem here is that Watchpoints & Breakpoints should share the
>>> Options class, and most of the StopInfo DoOnRemoval. I don’t think you’ll
>>> need to write a lot of new code to do this, it’s mostly ripping out th
Why? The macro states the intent explicitly, rather than having to deduce it
from details scattered through the class definition.
Jim
> On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev
> wrote:
>
> Doing it everywhere would be a public service IMO. I don't like macros
> either.
>
>
> On Sep 27, 2016, at 2:55 PM, Daniel Austin Noland
> wrote:
>
>> Folks on the outside of the SB API’s need to be able to pass callbacks in.
>> We don’t currently have any templates you need to instantiate or classes you
>> need to override to go from outside the SB API to inside it. So wha
1 - 100 of 483 matches
Mail list logo
