Re: [lldb-dev] logging in lldb

> 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

Re: [lldb-dev] logging in lldb

y 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 <lldb-dev@lists.llvm.org> > wrote: > >> >> On Dec 6, 2016, at 8:23 AM, Pavel Labath <lab...@google.com&g

Re: [lldb-dev] logging in lldb

> 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

Re: [lldb-dev] logging in lldb

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

Re: [lldb-dev] logging in lldb

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

Re: [lldb-dev] Bug in CommandObjectThreadUntil

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; >

Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server

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,

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

> 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

Re: [lldb-dev] LLDB hang loading Linux core files from live processes (Bug 26322)

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.

[lldb-dev] unittests/SymbolFile/PDB/Inputs/test-pdb.exe

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

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

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

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

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

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

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

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

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

> 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:

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

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

Re: [lldb-dev] RFC: Break/Watchpoint refactor

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

Re: [lldb-dev] RFC: Break/Watchpoint refactor

> 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,

Re: [lldb-dev] RFC: Break/Watchpoint refactor

> 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 > > wrote: > 4. All of these classes are "old school" (not

Re: [lldb-dev] RFC: Break/Watchpoint refactor

> 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

Re: [lldb-dev] running lldb-mi with LLDB_DISABLE_PYTHON

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

Re: [lldb-dev] LLDB Evolution - Final Form

> 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

Re: [lldb-dev] LLDB Evolution - Final Form

> 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

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

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

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

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] Problem with watchpoints

> 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

> 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] Problem with watchpoints

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] [OS X] debugserver SETUID root?

> 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.

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

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] Passing std::atomics by value

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

Re: [lldb-dev] Passing std::atomics by value

> 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

Re: [lldb-dev] Passing std::atomics by value

> 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

Re: [lldb-dev] showing CPU register flags

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] Breakpoint + callback performance ... Can it be faster?

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] LLDB Evolution

> 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

> 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

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

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

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] Inquiry about Error codes sent by lldb-server

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

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] Stop IDs for individual thread

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] Stop IDs for individual thread

> 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] Listing memory regions in lldb

> 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?

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] Listing memory regions in lldb

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

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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

> 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] break on exceptions/windows

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

> 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

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

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

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] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

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] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

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] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

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

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] Is it ok to use lldb_private from the driver?

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] Is it ok to use lldb_private from the driver?

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] Weird stop stack while hitting breakpoint

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] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

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

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] SymbolFile::FindGlobalVariables

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

> 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] How to enumerate stopped threads in C++ API?

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] Questions for module/symbol load/unload events

> 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] How to use the C++ API? No useful documentation?

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] No stopping event during launch(stop_at_entry=True) on Linux?

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?

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] Why is storing SBTarget in a private field causing random crash?

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

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] How to get SBTarget before AttachToProcessWithID?

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] Listening for thread events

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

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

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] Spurious process state change events

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] Spurious process state change events

> 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] Get source-map from python API?

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] Using control+left/right arrow to jump between words in the prompt

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] Linux core dump doesn't show listing when loaded

> 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?

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?

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

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

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] Attaching to a stopped (cored) process hangs lldb-server

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] Accessing DWARF information from C++

> 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

> 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] Thread resumes with stale signal after executing InferiorCallMmap

> 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] lldb fails to hit breakpoint when line maps to multiple addresses

> 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] Testing through api vs. commands

> 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

> 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

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] Breakpoints on inlined functions described by DW_AT_ranges

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] How does attach work on non-Windows?

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?

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

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

<    1   2   3   4   5   >