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] "target modules load" and breakpoints not working correctly

> On Mar 18, 2016, at 4:37 PM, Ted Woodward wrote: > > I found why the load addresses are getting dropped. When I do "target modules > load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new > load address for each section. Then when I attach, >

[lldb-dev] Weird stop stack while hitting breakpoint

Hi, Our IDE(wrapping lldb using python) works fine on Linux for simple hello world cases. While trying a real world case, I found whenever we set a source line breakpoint, then trigger the code path, lldb will send a stopped state process event, with thread.GetStopReason() being None and with

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

Btw: the breakpoint I set is: "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack frames. On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan wrote: > Hi, > > Our IDE(wrapping lldb using python) works fine on Linux for simple hello > world cases. While

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

Thanks for the info. I understand the multiple threads stopping at the same time issue. But I would think we should at least pick one stopped thread and set it as selected thread instead of some random thread with stop reason None. Also, in my repro case, there is only one thread that has stop

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

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

Yes, IIRC it’s the Microsoft compiler that uses a different mangling. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On Mar 18, 2016, at 4:14 PM, Jim Ingham wrote: > > Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you

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

Hmm, interesting, I got the stop reason from the lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason(). Is that thread not the one that stopped? But you are right, the breakpoint hits in another thread: thread #87: tid = 1006769, 0x0042eacd

[lldb-dev] exception "leaks" to debugger for win32

When starting a process on Win32 there's an internal exception (breakpint) that leaks to the debug caller: s 'Exception 0x8003 encountered at address 0x7789ccbc'#0 This one is dealt with by the debugger internally but there's still a StateType.eStateStopped event for it. On other

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

I found why the load addresses are getting dropped. When I do "target modules load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new load address for each section. Then when I attach, DynamicLoaderHexagonDYLD::DidAttach() calls

Re: [lldb-dev] Help needed regarding LLDB/MI

> On Mar 11, 2016, at 9:30 AM, RISHABH GUPTA via lldb-dev > wrote: > > Hello all, > > I have started using LLDB/MI but there are some commands that are not working > .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then launch > the application that I

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

You iterate over all the threads and ask each thread what its stop reason is. > On Mar 18, 2016, at 4:25 PM, Jeffrey Tan via lldb-dev > wrote: > > > Hmm, interesting, I got the stop reason from the >