Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

2015-11-04 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-07 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 4:06 PM, Eugene Birukov wrote: > > Even on Linux call to InferiorCallMmap does not fail consistently. In many > cases it survives. I just happened to have 100% repro on this specific > breakpoint in my specific problem. I.e. the burden of

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-07 Thread Jim Ingham via lldb-dev
Does it only happen for InferiorCallMmap, or does an expression evaluation that crashes in general set a bad signal on resume? I don't see this behavior in either case on OS X, so it may be something in the Linux support. Be interesting to figure out why it behaves this way on Linux, so

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

2015-10-07 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 4:39 PM, d...@burble.org wrote: > > On Mon, Oct 05, 2015 at 03:01:28PM -0700, Jim Ingham wrote: >> >> Given that, the best lldb can do is use heuristics, and the best heuristic I >> had was Block == basic block??? > > Can you at least check for branches then? (Yes,

Re: [lldb-dev] Process stops when two breakpoint are hit simulatenously, even though neither of them wants to stop

2015-10-08 Thread Jim Ingham via lldb-dev
> On Oct 8, 2015, at 1:03 AM, Keno Fischer via lldb-dev > wrote: > > Hi folks, > > I'm using the C++ API to create a breakpoint with callback. In the callback I > do some stuff and then always return false, to have the process continue. > This works great, except

Re: [lldb-dev] Testing through api vs. commands

2015-10-07 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 11:40 AM, Zachary Turner wrote: > > > > On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote: > > > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote: > > > >> > >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via

Re: [lldb-dev] Testing through api vs. commands

2015-10-07 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev > wrote: > > > > On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote: > > > > On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev > > wrote: > > > > Jim,

Re: [lldb-dev] Testing through api vs. commands

2015-10-07 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote: > >> >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev >> wrote: >> >> >> >> On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote: >> >> >>> On Oct 7, 2015, at 10:05

Re: [lldb-dev] Accessing DWARF information from C++

2015-10-13 Thread Jim Ingham via lldb-dev
> On Oct 13, 2015, at 9:03 AM, Stefan Kratochwil via lldb-dev > wrote: > > Hi, > > well, I found the llvm-dwarfdump tool in the tools directory *facepalm*... > I'll use that as a reference. > > That leaves the question about the two separate DWARF implementations.

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

2015-10-08 Thread Jim Ingham via lldb-dev
> On Oct 7, 2015, at 5:07 PM, Jim Ingham wrote: > > Another way to do this - which I thought about originally but rejected as too > much delicate machinery for the desired effect - is to add the notion of > "clusters" of locations to the breakpoint. Instead of eliding all

Re: [lldb-dev] How does attach work on non-Windows?

2015-08-26 Thread Jim Ingham via lldb-dev
There is a way on OS X. There is a sysctl that will give you information on the current process state, and one of the bits you get back says whether the process is being traced. sysctl's are a generic UNIX thing, but I don't know if the bit OS X uses is shared with other Unix's. Jim On Aug

Re: [lldb-dev] How does attach work on non-Windows?

2015-08-26 Thread Jim Ingham via lldb-dev
On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to initiate the attach, and then wait on the pid until it comes back with a SIGSTOP signal when the attach is completed. How the wait is done differs from system to system, but this is the general model. I have not

Re: [lldb-dev] Test suite rebuilding test executables many times

2015-08-25 Thread Jim Ingham via lldb-dev
It is fairly common practice (at least it is for me) when figuring out why a test failed, or adding to a test case, or when looking for a good example file to poke at, etc, to go to some relevant test directory, do a make then poke around a bunch. I don't generally remember to clean when I'm

Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges

2015-09-08 Thread Jim Ingham via lldb-dev
Ah, okay. For a while the llvm-dsymutil folks were trying to make the output of dsymutil & llvm-dsymutil identical so that they could be sure llvm-dsymutil was doing the right thing, so I'm a little surprised the two differ in this regard. But if it works with .o files & llvm-dsymutil I think

Re: [lldb-dev] Testing through api vs. commands

2015-09-15 Thread Jim Ingham via lldb-dev
> On Sep 15, 2015, at 4:23 PM, d...@burble.org wrote: > > I do still think we need some tests that verify commands run, but I think > those tests should focus not on doing complicated interactions with the > debugger, and instead just verifying that things parse correctly and the

Re: [lldb-dev] Testing through api vs. commands

2015-09-11 Thread Jim Ingham via lldb-dev
> On Sep 11, 2015, at 11:47 AM, Zachary Turner wrote: > > We'll probably rewrite tests that we find are failing specifically as a > result of issues like this, but I agree it's not worth re-writing everything > else except on an as-needed basis. > > To make the

Re: [lldb-dev] Testing through api vs. commands

2015-09-11 Thread Jim Ingham via lldb-dev
I have held from the beginning that the only tests that should be written using HandleCommand are those that explicitly test command behavior, and if it is possible to write a test using the SB API you should always do it that way for the very reasons you cite. Not everybody agreed with me at

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-16 Thread Jim Ingham via lldb-dev
Did you try waiting for an event on the listener you've passed to AttachToProcess? The last event after everything is done should be the notification to the public listener (i.e. your test_listener) that the process you attached to has stopped, and nobody is fetching that. Jim > On Sep 16,

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

2015-10-05 Thread Jim Ingham via lldb-dev
> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote: > > On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote: >> We currently coalesce breakpoints to avoid the user stopping multiple times >> on the same source line. This might have been done to avoid stepping issues >> we might have

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

2015-12-02 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Exclusively build and install LLDB?

2015-12-02 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Running lldb tests?

2015-12-02 Thread Jim Ingham via lldb-dev
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 >

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

2015-11-30 Thread Jim Ingham via lldb-dev
> 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 >

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

2015-11-30 Thread Jim Ingham via lldb-dev
the higher layers of the debugger. Jim > On Nov 30, 2015, at 5:24 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > >> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie <philippe.lav...@octasic.com> >> wrote: >> >> Sorry for th

Re: [lldb-dev] bindings as service idea

2015-11-19 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Stop IDs for individual thread

2016-06-03 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Stop IDs for individual thread

2016-06-03 Thread Jim Ingham via lldb-dev
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 <lldb-dev@lists.ll

Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt

2016-01-11 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Get source-map from python API?

2016-01-14 Thread Jim Ingham via lldb-dev
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: > >

Re: [lldb-dev] Why is storing SBTarget in a private field causing random crash?

2016-02-12 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Clang macro debug info

2016-02-09 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Listening for thread events

2016-01-29 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Understanding debugger launch events sequence

2016-01-29 Thread Jim Ingham via lldb-dev
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.

Re: [lldb-dev] Understanding debugger launch events sequence

2016-01-29 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?

2016-02-01 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

2016-02-23 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-02-23 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

2016-02-23 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-02-24 Thread Jim Ingham via lldb-dev
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 -

Re: [lldb-dev] Questions for module/symbol load/unload events

2016-02-29 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Spurious process state change events

2016-01-19 Thread Jim Ingham via lldb-dev
> 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,

Re: [lldb-dev] Spurious process state change events

2016-01-20 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-03-18 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

2016-03-18 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-03-18 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

2016-03-19 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

2016-03-19 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

2016-03-19 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-03-19 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] SymbolFile::FindGlobalVariables

2016-03-11 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Better error message for attaching to a process already being debugged

2016-03-09 Thread Jim Ingham via lldb-dev
> 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 >

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

2016-03-28 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Weird stop stack while hitting breakpoint

2016-03-19 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] How to enumerate stopped threads in C++ API?

2016-03-03 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

2016-03-28 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] break on exceptions/windows

2016-04-04 Thread Jim Ingham via lldb-dev
"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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-09 Thread Jim Ingham via lldb-dev
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 > store line information, it's just something we cons

Re: [lldb-dev] Listing memory regions in lldb

2016-05-12 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Listing memory regions in lldb

2016-05-12 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Listing memory regions in lldb

2016-05-16 Thread Jim Ingham via lldb-dev
> On Thu, May 12, 2016 at 11:09 AM Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > 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 Sec

Re: [lldb-dev] Push work-in-progress plugin for Process NetBSD?

2016-05-16 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-06 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

2016-05-06 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-12 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Trying to understand how Expression Evaluation works

2016-07-20 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] No event generated after a SBThread::JumpToLine() call

2016-07-18 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Question about -break-insert in lldb-mi

2016-07-11 Thread Jim Ingham via lldb-dev
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) >

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2016-07-06 Thread Jim Ingham via lldb-dev
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: [lldb-dev] Scripting on frame finish?

2016-08-05 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] Inquiry about Error codes sent by lldb-server

2016-06-30 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Calling multiply defined symbols

2016-06-29 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Breakpoint + callback performance ... Can it be faster?

2016-08-16 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-03 Thread Jim Ingham via lldb-dev
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.

Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-03 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-03 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Tab completion for variable names, etc.

2017-01-23 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Navigating STL types

2017-01-23 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Why SBValue::Cast is deprecated and how to replace it with expression?

2017-01-30 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-20 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Too many ModuleSP references

2017-02-21 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Too many ModuleSP references

2017-02-21 Thread Jim Ingham via lldb-dev
> On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > >> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >>> - StepOverBreakpointTestCase: Have the test no

Re: [lldb-dev] Too many ModuleSP references

2017-02-21 Thread Jim Ingham via lldb-dev
> On Feb 21, 2017, at 4:26 PM, Greg Clayton <gclay...@apple.com> wrote: > >> >> On Feb 21, 2017, at 9:36 AM, Jim Ingham via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> Thanks for digging into this. >> >>

Re: [lldb-dev] Too many ModuleSP references

2017-02-21 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] showing CPU register flags

2016-08-17 Thread Jim Ingham via lldb-dev
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,

Re: [lldb-dev] [LLDB on windows] Step out is not working

2017-02-28 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] [OS X] debugserver SETUID root?

2016-09-01 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] Symbol Server for everyone.

2016-08-30 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Help with Xcode crash on lldb_private::(anonymous namespace)::parse_builtin_type

2016-08-29 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Problem with watchpoints

2016-09-09 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] Problem with watchpoints

2016-09-12 Thread Jim Ingham via lldb-dev
> 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. >>>

Re: [lldb-dev] Problem with watchpoints

2016-09-12 Thread Jim Ingham via lldb-dev
> 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

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

2016-09-15 Thread Jim Ingham via lldb-dev
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: > >

Re: [lldb-dev] Connecting to lldb-rpc-server

2016-10-07 Thread Jim Ingham via lldb-dev
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

[lldb-dev] Asserts in StringRef::front

2016-10-06 Thread Jim Ingham via lldb-dev
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

  1   2   3   4   >