This isn't an issue with ObjC support in general, but rather shows that ObjC
string constants are odd beasts. You can work around this pretty easily by
making dynamic strings:
(lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String:
"This is a string"];
(lldb) expr string
> On Oct 5, 2016, at 10:06 AM, Rex Fenley wrote:
>
> Jim,
>
> That doesn't seem to work for us. We're using lldb packaged with Xcode 8 fyi.
> (lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String:
> "This is a string"];
>
>
>
> ; Function Attrs: nounwind
>
> define i
You would have to be really careful about using "debugger variables" whose name
is not decorated with a "$". After all, this is introducing a global variable,
which will be shadowed by local variables, ivars, file statics for the current
frame's CU, etc. So using the code you've added at vario
This isn't the appropriate place to discuss lldb-swift build problems, since
the swift support is not actually in the llvm.org tree. A better mailing list
would be:
https://lists.swift.org/mailman/listinfo/swift-lldb-dev
Jim
> On Oct 5, 2016, at 12:25 PM, Rex Fenley wrote:
>
> Hey!
>
> I t
I fixed a bug in CommandObject::Execute that cause test-suite crashes when
running with an Assert build of llvm (r283479.)
The test was doing:
break modify -c ''
which is the way you unset a condition on a breakpoint.
So the StringRef for that option value was empty, and it appears that you
a
Enrico is right. At present, each connection to the lldb-rpc-server gets its
own SBDebugger, so you wouldn't be able to talk to the debugger that Xcode is
using for its process.
Even if that was changed, then you'd run into other problems, for instance, at
present only one Listener can wait fo
The SB API's in general don't send events about changing the things that they
directly change. It seems awkward to say "Do X" and then have to field an
event telling you that "X was done". And the return from the function
generally tells you whether what you tried to do succeeded or not, so it
Over in the Swift GitHub, somebody filed:
https://bugs.swift.org/browse/SR-3147
with the claim that this file contains a trojan? Dunno if this is bogus or
not, but it's worth somebody on the Windows side checking it out...
Jim
___
lldb-dev mailing l
I think that approach is kind of a bandaid.
Core files can't resume, so it would be better to figure out why telling a core
file which can't resume to resume caused us to go into a tail spin. That
should just fall out of WillResume returning false or some other better general
signal. Specia
> On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev
> wrote:
>
> I was going through doing some routine StringRef changes and I ran across
> this function:
>
> std::lock_guard guard(m_mutex);
> assert(GetStackID() ==
> prev_frame.GetStackID()); // TODO: remove this after s
> On Nov 14, 2016, at 1:44 PM, Zachary Turner wrote:
>
> If the swap is correct, then wouldn't we also need to swap the variable list?
That would make things more symmetrical, though all your doing is skipping the
shared pointer ref count manipulations so it isn't terribly important.
Jim
>
> On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev
> wrote:
>
> Is “image search-paths add” supposed to remove all breakpoints from the
> remote server? I don’t think it should be doing this.
>
> PathMappingList::Append calls Target::ImageSearchPathsChanged, which calls
> Target::Set
That seems like the cleanest way to do things. It doesn’t look like the Darwin
& MacOS dynamic loaders don’t have any state that they wouldn’t correctly
re-compute mid-flight. But for instance when the shared library list goes
away, the runtime plugins might also need to get unset and reset, a
Obviously a bug. Fixed in r287386.
Jim
> On Nov 18, 2016, at 11:47 AM, Zachary Turner via lldb-dev
> wrote:
>
> CommandObjectThreadUntil::DoExecute() has the following code:
>
> for (size_t i = 0; i < num_args; i++) {
> uint32_t line_number;
> line_number = String
Sorry, I'm being dense. What is Dx?
Jim
> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>
> I have created straw-man implementation of such an interface in
> Dx, together with some examples of how it's used, and I'd like to
___
lldb-dev ma
Ah, cool! I'll have a look.
Jim
> On Dec 6, 2016, at 8:57 AM, Pavel Labath wrote:
>
> On 6 December 2016 at 16:51, Jim Ingham wrote:
>> Sorry, I'm being dense. What is Dx?
>>
>> Jim
>>
>>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>>
>>> I have created straw-man implementation
> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>
> Hello all,
>
> I've been thinking about how to simplify the way we do logging in
> lldb. The main two problems I see are:
> a) inability to print complex types easily - this was always tricky,
> but lately has become even more problematic, a
is crucial.
Sorry if this is obvious to folks, but on the off chance it isn't, it's worth a
few bytes to restate it.
Jim
> On Dec 6, 2016, at 9:39 AM, Jim Ingham via lldb-dev
> wrote:
>
>>
>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>
>>
> On Dec 6, 2016, at 10:07 AM, Zachary Turner wrote:
>
> Merging the thread over from lldb-commits:
>
>
>
> On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator
> wrote:
> jingham added a comment.
>
> I not infrequently have some non-trivial code in the "if (log)" block that
> gather
> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote:
>
>> I think having a convenience to add function name decorators is fine, but we
>> need a way not to do it all the time. We have logs that don't have function
>> names because they log over several functions, and having the different
>> na
Yes, writing that long path every time you run a test case was indeed the
reason for that symlink. I stood it for a couple of weeks before it drove me
round the bend! You want it to be a real path and not just have the test suite
accept partial paths because it is really handy to use the shell
Yeah, I’m with Jason. I don’t find the current state of things hard to read or
work with.
The proposed solutions seem a little uglier to me. I try to avoid macros, to
me it makes it look like the code is shouting at you, giving the log lines more
prominence then they deserve in the overall
If that works, can you add it to the lldb-gdb.html document?
Jim
> On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev
> wrote:
>
> Try “image search-paths add” as a replacement for “set solib-search-path”
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is
All the lldb.llvm.org web pages are taken from the www directory in the
sources. So just change it there and the web page will get updated.
The one you want is lldb-gdb.html.
Jim
> On Jan 20, 2017, at 4:44 PM, Eugene Birukov wrote:
>
> Sorry, never done that - where this HTML is located and
This is a long-standing missing feature in lldb. We delegate to clang the
parsing of expressions, so we're going to have to either create a separate
parser for symbol completion or figure out how to get clang to parse up to the
cursor and then tell us what it has parsed so far. This would be a
lldb has "synthetic child providers" for most of the STL collection types, so
we do show all the child values, for instance my_vec is a std::vector and:
(lldb) expr my_vec
(std::__1::vector >) $0 = size=10 {
[0] = 0
[1] = 1
[2] = 2
[3] = 3
[4] = 4
[5] = 5
[6] = 6
[7] = 7
[8] = 8
Cast is deprecated because it isn't a real C++ cast. In particular if you cast
a pointer to a base class to it's parent class, it doesn't do the work to
offset the pointer to take into account the position of the base class in it's
parent. All it does is extract the address of the original val
> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev
> wrote:
>
> Non-stop mode is a huge change to the core of LLDB isn’t it. I think you
> might think this is easier than it actually is to enable in LLDB?
>
> Is non-stop mode where you can leave some threads running while others are
>
> On Feb 3, 2017, at 10:51 AM, Ted Woodward wrote:
>
> I'm working on plumbing the existing non-stop mode switch
> (target.non-stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.
>
> The remote OS is very thread-heavy, and the remote stub doesn't limit the
> debugger to the curren
I don't know that that's the whole story. According to the gdb-remote protocol
specs, the async packet (%Stop) may be sent at any time. So I would expect
that if, after you got the OK response to the vStopped query, another running
thread stopped or crashed you would get another %Stop packet.
Thanks for digging into this.
Maybe a better option would be to have IRExecutionUnit hold a
SymbolContextScope, rather than a SymbolContext. We started out with
SymbolContext's because they were convenient but they hold too many things
alive so when we run into SymbolContext's we've been conve
mman.h, which defines these flags, says:
* The MAP_RESILIENT_* flags can be used when the caller wants to map some
* possibly unreliable memory and be able to access it safely, possibly
* getting the wrong contents rather than raising any exception.
* For safety reasons, such mappings have to
> On Feb 21, 2017, at 4:26 PM, Greg Clayton wrote:
>
>>
>> On Feb 21, 2017, at 9:36 AM, Jim Ingham via lldb-dev
>> wrote:
>>
>> Thanks for digging into this.
>>
>> Maybe a better option would be to have IRExecutionUnit hold a
>> Symbol
> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev
> wrote:
>
>> - StepOverBreakpointTestCase: Have the test not store the breakpoints
>> in the test case object. Basically, declare that this is not a bug,
>> and it's the users responsibility to clean up necessary objects.
>
> It would b
> On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev
>> wrote:
>>
>>> - StepOverBreakpointTestCase: Have the test not store the breakpoints
>>> in the test case o
I presume you meant "step over is not working" in the Subject?
The call to std::cout... ends up inserting quite a number of inlined function
calls into my_func. clang is not always great at generating coherent
line-table and inlined subroutine ranges for deeply nested inlining, so that
the ste
We encounter low pc values of 0 quite often macOS, since we leave the DWARF in
.o file and then use a debug-map to fix up the addresses (and remove unused
functions). The first function in a .o file is often at 0. Just a data point
in favor of choosing something other than a low pc of 0 to mea
> On Mar 16, 2017, at 2:43 PM, Kamil Rytarowski via lldb-dev
> wrote:
>
> On 16.03.2017 11:55, Pavel Labath wrote:
>> On 16 March 2017 at 00:43, Kamil Rytarowski wrote:
>>>
>>> TODO:
>>> - Fixing software breakpoints support,
>
> Fixed!
>
> 267->596 of succeeded tests out of 1200+ - please
The main consumer of thread stop reasons is the execution control (ThreadPlans
- which handle stepping & function calling - and StopInfo::PerformAction which
handles breakpoint/watchpoint hits). The only bad effect of populating all the
threads with the whole process signals is if any of the pl
There's no reason why you couldn't do a C REPL, so having the framework for it
in llvm.org seems reasonable. Just the generic part is enough trickery it is
worth sharing.
I'm not sure why you care about the fact that Repl.h includes something from
Command, but if you do then probably the easie
ScriptInterpreters are about providing a way to script lldb.
The REPL in lldb is about giving users an interactive way to play with a
compiled language with no requirement that it bind to lldb in particular.
The two seem fairly different concepts.
Jim
> On Mar 21, 2017, at 6:44 PM, Zachary
> On Mar 21, 2017, at 6:58 PM, Jim Ingham wrote:
>
> There's no reason why you couldn't do a C REPL, so having the framework for
> it in llvm.org seems reasonable. Just the generic part is enough trickery it
> is worth sharing.
>
> I'm not sure why you care about the fact that Repl.h include
> On Mar 21, 2017, at 7:16 PM, Zachary Turner wrote:
>
>
> On Tue, Mar 21, 2017 at 7:10 PM Jim Ingham wrote:
>
> > On Mar 21, 2017, at 6:58 PM, Jim Ingham wrote:
> >
> > There's no reason why you couldn't do a C REPL, so having the framework for
> > it in llvm.org seems reasonable. Just th
> On Mar 21, 2017, at 7:14 PM, Zachary Turner wrote:
>
>
> On Tue, Mar 21, 2017 at 7:07 PM Jim Ingham wrote:
> ScriptInterpreters are about providing a way to script lldb.
>
> The REPL in lldb is about giving users an interactive way to play with a
> compiled language with no requirement tha
That seems reasonable, but I don't think it would solve your immediate problem.
The problem here is that the REPL has two parts, the part that is extensible to
support the actual language you want to write a REPL for, and a part that is
"any particular REPL is just an extension of the express
BTW, Jason noticed that somebody had deleted the LIBLLDB_LOG_TEMPORARY log
channel.
Since it looks like one of those things that there's no use for, it's easy to
think deleting it is a good cleanup. But it's actually quite useful as a way
to quickly tailor-make a particular set of logs. Som
ostly in the "posix"
> channel, but this I deleted this one as well.. I didn't call that out
> explicitly during review, as it seemed easy to add back those that turn out
> to be needed.
>
> sorry about the troubles,
> pl
>
> On 4 April 2017 at 00:22, Jim
memory write's argument ingestion was changed as part of the StringRefifying of
Args so that we get:
(lldb) memory write &buffer 0x62
error: '0x62' is not a valid hex string value.
That seems unexpected and not desirable. What's going on is that the default
format is hex, and if the format is
27;d rather not change it (intentionally) if we don't have to.
Jim
> On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev
> wrote:
> memory write's argument ingestion was changed as part of the StringRefifying
> of Args so that we get:
>
> (lldb) memory write &a
t way forever, and I don't know who's relying on that
> behavior, so I'd rather not change it (intentionally) if we don't have to.
>
> Jim
>
> > On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev
> > wrote:
> > memory write's argument i
tial usage. So I went with
detecting the 0x by hand and treating that separately (r299609).
Why does getAsInteger return false if it succeeds in getting an integer? That
just seems weird to me.
Jim
> On Apr 5, 2017, at 4:36 PM, Jim Ingham via lldb-dev
> wrote:
>
> It does
the only consequential usage. So I went
> with detecting the 0x by hand and treating that separately (r299609).
>
> Why does getAsInteger return false if it succeeds in getting an integer?
> That just seems weird to me.
>
> Jim
>
>
>> On Apr 5, 2017, at 4
x, so that
> > should be okay. Other than that this was the only consequential usage. So
> > I went with detecting the 0x by hand and treating that separately (r299609).
> >
> > Why does getAsInteger return false if it succeeds in getting an integer?
> > Th
BTW, lldb has a setting:
settings set target.process.extra-startup-command
In the Process GDBRemote case if this is set lldb sends whatever packet you
specify to the stub before starting the normal sequence.
We added support in debugserver for a QSetLogging packet, which we use like:
QSetLogg
The contract with the SB API is that changes are only additive. So you only
need to track versions if there's an API that was added at some point, and you
want to make sure you have a version of the headers with that API. In practice
that means you shouldn't need to keep updating the SB API's
> On Apr 13, 2017, at 9:06 AM, Scott Smith via lldb-dev
> wrote:
>
> Ok. I tried doing something similar to gdb but was unable to make any
> headway because they have so many global variables. It looked more promising
> with lldb since there were already some locks.
>
> I assume you're tal
No, this was an inadvertent side effect of rewriting the command parser to use
llvm's StringRef's. Please file a bug (or submit a patch!)
Jim
> On Apr 18, 2017, at 10:49 PM, via lldb-dev wrote:
>
> Hello,
>
> The query to repeat a command from history used to be ! but
> it looks like that d
> On Apr 19, 2017, at 7:37 AM, Pavel Labath via lldb-dev
> wrote:
>
> It is on purpose, although whether that purpose is worthwhile is debatable...
>
> We chose to run release builds there so to align the bots closer to the
> binaries we release. Unfortunately, it does mean we run into situat
ook
>
> On Wed, Apr 19, 2017 at 10:33 AM Jim Ingham via lldb-dev
> wrote:
> No, this was an inadvertent side effect of rewriting the command parser to
> use llvm's StringRef's. Please file a bug (or submit a patch!)
>
> Jim
>
> > On Apr 18, 2017, at 10:
We started out with the philosophy that lldb wouldn't touch any more
information in a shared library than we actually needed. So when a library
gets loaded we might need to read in and resolve its section list, but we won't
read in any symbols if we don't need to look at them. The idea was th
Somebody is probably setting an internal breakpoint for some purpose w/o
scoping it to the shared library it's to be found in. Either that or somebody
has broken lazy loading altogether. But that's not intended behavior.
Jim
> On Apr 27, 2017, at 7:02 AM, Scott Smith wrote:
>
> So as it tur
7, at 10:51 AM, Pavel Labath wrote:
>
> It's the gdb jit interface breakpoint. I don't think there is a good
> way to scope that to a library, as that symbol can be anywhere...
>
>
> On 27 April 2017 at 18:35, Jim Ingham via lldb-dev
> wrote:
>> Somebody i
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
ever.
> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
> kevent, so we should probably set that up too.
>
> -Chris
>
>
>> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev
>> wrote:
>>
>> Seems to me a better UI would
> 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
I'm mostly but not entirely tongue in cheek wondering why we aren't calling
llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
that's a minor point.
If it is actually causing confusion (I haven't experienced such yet) I don't
mind typing some extra letters.
As we've d
> On May 1, 2017, at 11:48 AM, Zachary Turner wrote:
>
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
> I'm mostly but not entirely tongue in cheek wondering why we aren't calling
> llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
> that's a minor point.
>
BTW, I'm interested to know if you have some analysis which leads you to think
that propagating unchecked errors actually is a big problem in lldb, or are you
just doing this to remove a spelling collision? I see a lot of bugs for lldb
come by, but I really haven't seen many that this sort of f
> On May 1, 2017, at 12:54 PM, Zachary Turner wrote:
>
> The rename is just to avoid the spelling collision. Nothing in particular
> leads me to believe that unchecked errors are a source of major bugs.
>
> That said, I have some short term plans to begin making use of some llvm
> library cl
> On May 1, 2017, at 2:51 PM, Zachary Turner wrote:
>
> I think we agree about the SB layer. You can't have mandatory checking on
> things that go through the SB API. I think we could code around that though.
>
> Regarding the other point, I actually think force checked errors *help* you
>
> On May 1, 2017, at 3:12 PM, Zachary Turner wrote:
>
> Does Xcode ship with a build of LLDB that has asserts enabled? Because if
> not it shouldn't affect anything. If so, can you shed some light on why?
Not sure that's entirely relevant. The point is not to make failure points
assert the
> On May 1, 2017, at 3:29 PM, Zachary Turner wrote:
>
> I'm confused. By having the library assert, you are informed of places where
> you didn't do a good job of backing from errors, thereby allowing you to do a
> *better* job.
>
> You said this earlier:
>
> > But a larger point about asse
> On May 1, 2017, at 4:52 PM, Zachary Turner wrote:
>
> Yea, grouping the error and the result together is one of the most compelling
> features of it. It's called Expected, so where we would currently write
> something like:
>
> int getNumberOfSymbols(Error &Err) {}
>
> or
>
> Error getNu
I'm not sure about Linux, on OS X lldb will mmap the debug information rather
that using straight reads. But that should just be once per loaded module.
Jim
> On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev
> wrote:
>
> I've been trying to improve the parallelism of lldb but have run in
> On May 4, 2017, at 7:15 AM, Scott Smith via lldb-dev
> wrote:
>
> I would like to change the list of threads that lldb presents to the user for
> an internal application (not to be submitted upstream). It seems the right
> way to do this is to write an OperatingSystem plugin.
>
> 1. Can I
IIUC Linux doesn't include the system libraries in the core files, makes them
much smaller, but also makes reconstructing them a bit more work.
Jim
> On May 8, 2017, at 11:34 AM, John Lindal via lldb-dev
> wrote:
>
> I regularly load core files on OSX, and it seems to work fine. Is Linux
>
> On May 10, 2017, at 6:28 PM, Zachary Turner wrote:
>
> Yes, this is just the rename.
>
> Regarding the naming, if you call it ErrorAnd, or WithError, or anything that
> includes the word error, you are implying that something actually went wrong.
> I don't think that's the intended use cas
One of the strategies for speeding up ObjC dispatch was for the runtime to
include a vtable that did direct dispatch for some very common methods (e.g.
-[NSArray count]). Since method dispatch is dynamic, we always have to figure
out the implementation for a given selector, so we had to be able
This is really an orthogonal problem to the thread plans. They are about
answering the question "how do I get from A to B?". But you want to get the
right answer to "If I land in B, do I want to stop there?" This sort of
question is answered with the "ShouldStopHere" mechanism (see
source/Ta
We designed lldb to be as lazy as possible in loading symbol information from
the shared libraries as they get loaded. If this is causing you problems, the
first thing to do is to figure out why lldb is pulling in more information than
you need. For instance, it looks like on Linux the gdb JIT
In general, if lldb can find host-side copies of binaries that match the ones
it finds on the device, it will do all symbol reading against the host copies.
In the case of an OS X host debugging iOS, lldb uses Spotlight and a few other
tricks to find the host-side binaries. You can also use "a
I see you also asked this on lldb-commits. This was a better list for that
question, but I responded on the other list. In short, unless you need to use
the MI because you have to support both gdb & lldb, I think you will be much
happier using the SB API's than the MI.
Jim
> On May 26, 2017,
Because we try as much as possible to let the compiler figure this sort of
thing out for us, we implement the transparent lookups for this & self by
compiling our expression in a context that poses as a method of the class whose
method we are stopped in. For instance, for ObjC, we construct a c
Bug reports are here:
https://bugs.llvm.org
It's the same system as for llvm, just specify lldb as the product.
Jim
> On May 28, 2017, at 8:11 AM, Dr. Rolf Jansen via lldb-dev
> wrote:
>
> I managed to build LLDB on a Beaglebone Black running a snapshot (May 20th)
> of FreeBSD 12.0-CURRENT
DW_AT_location can easily
> handle the lookup of some field in a struct. Of course, this is
> assuming you are actually able to modify the compiler.
>
> (disclaimer: I know next to nothing, when it comes to objc)
>
> On 26 May 2017 at 23:25, Jim Ingham via lldb-dev
> wrote:
>
Because the gdb remote protocol docs explicitly state:
The error response returned for some packets includes a two character error
number. That number is not well defined.
we don't put much stock in the actual error numbers.
If you can determine that you are talking to lldb-server, then we co
Right. I wasn't actually arguing one method over the other. Mostly pointing
out that you can't take error numbers seriously in general, and that
consequently if we go the error number route, you have to know you are talking
to lldb-server and particularly one that has rational error numbers.
This is Greg's area, he'll be able to answer in detail how the name chopper
gets used. IIRC it chops demangled names, so it is indirectly a client of the
demangler, but it doesn't use the demangler to do this directly. Name lookup
is done by finding all the base name matches, then comparing th
demangler was still
> faster. I forget (and apparently didn't write down) how much it mattered,
> but post this change I think was single digit %.
>
> https://reviews.llvm.org/D32500
>
>
> On Thu, Jun 22, 2017 at 11:07 AM, Jim Ingham via lldb-dev
> wrote:
>
The gdb remote protocol documents say the error numbers are not well defined.
They are not meant to have any meaning.
The lldb Status (née Error) objects have different namespaces, some of which
(like the Posix errors) have significant numbering, so the numbers in those
cases are preserved, si
The recent and not so recent moves from Core to Utility, etc. have left the
information in this file stale. It was last updated in 2013...
Can one of the people doing this work (Zachary, Pavel...) take a look at this
and bring it up to date, and maybe make more clear the current intentions fo
In lldb as it stands now, any action in a breakpoint command callback that
continues the process you are debugging (step, step-out, fin, etc) will
terminate the callback. That restriction is a side effect of the fact that the
lldb command interpreter is not re-entrant. It couldn't handle the s
> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
> wrote:
>
> There's a function in OptionValueProperties
> (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
> line 234):
>
> const Property *OptionValueProperties::GetPropertyAtI
Was this just curiosity, or was this getting in your way somehow?
Jim
> On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
>> wrote:
>>
>> There's a function in OptionValuePr
t;
> Sean
> On 7/21/17 4:51 PM, Jim Ingham wrote:
>> Was this just curiosity, or was this getting in your way somehow?
>>
>> Jim
>>
>>
>>> On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
>>>
>>> wrote:
>>>
>
gt;
> Maybe I'm missing something, however.
>
> Jim
>
>>
>> Sean
>> On 7/21/17 4:51 PM, Jim Ingham wrote:
>>> Was this just curiosity, or was this getting in your way somehow?
>>>
>>> Jim
>>>
>>>
>>>>
> On Jul 24, 2017, at 3:03 AM, Steve Trotter via lldb-dev
> wrote:
>
> Hi all,
>
> I'm fairly new to LLVM and LLDB, I became interested in this project about 3
> months back and I'm hoping to be able to contribute to improving LLDB in
> time. I've been trying to get to grips with the code an
Will do, just making sure it builds.
Jim
> On Aug 1, 2017, at 2:41 AM, Vadim Macagon via lldb-dev
> wrote:
>
> Hi,
>
> My changes in r309664 (https://reviews.llvm.org/D35881) broke the XCode
> build, I'm guessing because I didn't update the XCode project(s) to reference
> these new files:
>
One of the rules of the SB API's both on the Python & C++ side is that we
maintain backwards compatibility (up to some time in the Future when we'll
declare a SB 2.0...)
So if you compile your tool against some version of the framework, you should
be able to run against any newer version.
Apple
> On Aug 7, 2017, at 9:15 PM, Mikhail Seriukov wrote:
>
> Hi Jim, thank you for your response!
>
> If I choose to build the framework, there is a code signing problem.
> For the debugserver (and lldb-server?) we need lldb_codesign certificate.
> I was wondering if I could use my Mac developer
101 - 200 of 483 matches
Mail list logo
