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

[Keno Fischer via lldb-dev]

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 when a breakpoint hit is coincident with another
breakpoint (in my case I ran into this with both the jit breakpoint and the
gdb_image_notifier breakpoint). I turned on logging and saw:

Process::PerfomAction returning from action with m_should_stop: 1
Process::PerfomAction returning from action with m_should_stop: 0

so I added the breakpoint id to the log to figure out which breakpoint was
causing the stop:

Process::PerfomAction returning from action at id -1 with m_should_stop: 1
Process::PerfomAction returning from action at id 2 with m_should_stop: 0

where -1 is the JIT breakpoint. Any ideas why this might be happening?
Looking through the rest of the log, I never see the message about
Process::PerfomAction when -1 only is hit (though always when only 2 is
hit). Is the second breakpoint somehow forcing PerformAction to be called
on all of them even though it shouldn't be?

Keno
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

Hi,

I believe the SIGILL problem you are referring to is the problem
described in bug . This
was fixed in r244875, but unfortunately, this was after 3.7 branch so
this patch did not make it there. I recommend to try the master
branch, I think this should work for you now (and do let me know if
the problem persists).

pl

On 8 October 2015 at 00:20, Jim Ingham via lldb-dev
 wrote:
>
>> 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 investigation is on 
>> me, since I cannot share my program.
>>
>> But I am not looking at this SIG_ILL yet. Whatever the problem is with mmap 
>> - the client must not carry this signal past expression evaluation. I.e. I 
>> believe that we can construct any arbitrary function that causes signal, 
>> call it from evaluate expression, and then continue would fail. I suspect 
>> that this problem might be applicable to any POSIX platform.
>
> It doesn't happen on OS X, though when it comes to signal handling in the 
> debugger OS X is an odd fish...
>
>>
>> As it turned out, my initial analysis was incorrect. m_resume_signal is 
>> calculated from StopInfo::m_value (now I wonder why do we need two fields 
>> for that?).
>
> The signal that you stop with is not necessarily the one you are going to 
> resume with.  For instance, if you use "process handle SIG_SOMESIG -p 0" to 
> tell lldb not to propagate the signal, then the resume signal will be 
> nothing, even though the stop signal is SIG_SOMESIG.
>
>> And after mmap call, m_stop_info on the thread is null. So, my current 
>> theory is that there is an event with SIG_ILL that is stuck in the 
>> broadcaster and is picked up and processed much later.
>
> When the expression evaluation completes, the StopInfo from the last 
> "natural" stop should be put back in place in the thread.  After all, if you 
> hit a breakpoint, run an expression, then ask why that thread stopped, you 
> want to see "hit a breakpoint" not "ran a function call".  Sounds like that 
> is failing somehow.
>
> Jim
>
>
>>
>> > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
>> > InferiorCallMmap
>> > From: jing...@apple.com
>> > Date: Wed, 7 Oct 2015 15:08:18 -0700
>> > CC: lldb-dev@lists.llvm.org
>> > To: eugen...@hotmail.com
>> >
>> > 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 
>> > whatever we do we're implementing it consistently.
>> >
>> > Jim
>> >
>> >
>> >
>> > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
>> > >  wrote:
>> > >
>> > > Hi,
>> > >
>> > > I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint 
>> > > and if I call SBFrame::EvaluateExpression() there, when I let it go it 
>> > > terminates with SIG_ILL on an innocent thread. I dug up into this, and 
>> > > there seems to be two independent problems there, this mail is about the 
>> > > second one.
>> > >
>> > > • EvaluateExpression() calls Process::CanJIT() which in turn executes 
>> > > mmap() on the inferior. This mmap gets SIG_ILL because execution starts 
>> > > at address which is 2 bytes before the very first mmap instruction. I am 
>> > > still looking why LLDB server decided to do that - I am pretty sure that 
>> > > the client asked to set the program counter to correct value.
>> > > • So, the thread execution terminates and the signal is recorded on 
>> > > Thread::m_resume_signal. This field is not cleared during 
>> > > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the 
>> > > program after breakpoint.
>> > >
>> > > So, what would be the best way to deal with the situation? Should I add 
>> > > "resume signal" field to ThreadStateCheckpoint? Or would StopInfo be a 
>> > > better place for that? Or something else?
>> > >
>> > > Thanks,
>> > > Eugene
>> > > ___
>> > > lldb-dev mailing list
>> > > lldb-dev@lists.llvm.org
>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25106] New: lldb crashes when reading a core file

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25106

Bug ID: 25106
   Summary: lldb crashes when reading a core file
   Product: lldb
   Version: 3.7
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@mixedrealities.no
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15031
  --> https://llvm.org/bugs/attachment.cgi?id=15031&action=edit
Minimal test case needed to reproduce the bug; 7z archive

I compile the attached C++ program with clang++ z.cc, run it and receive
segmentation fault as expected. lldb crashes when trying to load the produced
core file:

vrba@zax:/tmp$ lldb 
(lldb) target create -c core a.out
Segmentation fault

gdb has no problems with loading the core file and showing the source.

vrba@zax:/tmp$ clang++ --version
Debian clang version 3.7.0-svn247539-1~exp1 (branches/release_37) (based on
LLVM 3.7.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

[I have installed Debian packages provided by the LLVM project.]


The attached archive contains the source code, the executable and the produced
core file.

This is the stack trace when lldb crashed:
#0  0x76579120 in lldb_private::ArchSpec::GetMachine() const ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#1  0x7691674f in
RegisterContextPOSIX_x86::RegisterContextPOSIX_x86(lldb_private::Thread&,
unsigned int, lldb_private::RegisterInfoInterface*) () from
/usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#2  0x775be764 in
RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&,
lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&,
lldb_private::DataExtractor const&) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#3  0x775bf212 in
ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#4  0x775becdb in ThreadElfCore::GetRegisterContext() () from
/usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#5  0x769b97cc in lldb_private::StackFrameList::GetFramesUpTo(unsigned
int) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#6  0x769ba22b in
lldb_private::StackFrameList::ResetCurrentInlinedDepth() ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#7  0x769e0242 in
lldb_private::Thread::ShouldStop(lldb_private::Event*) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#8  0x769e68f6 in
lldb_private::ThreadList::ShouldStop(lldb_private::Event*) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#9  0x769a3ad3 in
lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#10 0x769a3bb1 in
lldb_private::Process::HandlePrivateEvent(std::shared_ptr&)
()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#11 0x769a6a1c in lldb_private::Process::RunPrivateStateThread(bool) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#12 0x766d1eb2 in
lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) ()
   from /usr/lib/x86_64-linux-gnu/liblldb-3.7.so
#13 0x75a3a0a4 in start_thread (arg=0x7fffeedd8700) at
pthread_create.c:309
#14 0x7491704d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Preliminary support for NetBSD

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05.10.2015 21:46, Todd Fiala wrote:
> Seems like a great idea.  (Ed, is that something you might be able
> to review?)
> 

The first patch is already proposed:
http://reviews.llvm.org/D13334

> Hopefully you have access to other platforms to test if it's
> breaking anything?  (Most likely candidates would be FreeBSD and
> Linux/Android, I'd suspect, depending on how much you're having to
> change things).
> 

I just run just NetBSD exclusively (desktop, development). My Linux or
FreeBSD (unlikely frequent) is limited and at that places I don't
develop lldb. I don't remember when I touched other systems, perhaps
Tru64 2 years ago.

It's not that crucial anyway, as there is review board.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWFkOfAAoJEEuzCOmwLnZslOYQAICJ/lnkehumJOD8TQ7NfPvD
XZXI2Y/AuXRNbCbDHp1LxCmY8ZrVkdJrGEttpKQhS53UgYHWEzd6jZlt+tQE5qmW
pMr7p+oEK58q6ui1igDUw+Qr+RFHzjNjPuaAu4tnnO7UmU94kSlrrRcsnEIbALcu
Rdj9K4dlysZlvepm7ogAP8kGE9tzRb0+2S0wJHFLvseesShMeqiDrZuH+6WGrh4K
KZNfL1rU307Va79Q/mx1ENyjSHjUkSOLR1teMvecSl3sIZVN920arGcXojSN4lcP
U53Lb7v5ngPnhIzyQ3DP2IC3SSyBppOqeJsdZtEoGIdizK3p91YhRbKccDUA37VV
G2QlSy8wl2tFf4yPoE+ZDUslGImvj8b9ovSR5sbLNVD128XrV5OpuO7G7WIB/xJK
RHBOijyfb99sVxq3F83jHsCKBqB1okuf9GekCfaN5/GMFt7WMaPoJloCFD/UkMfZ
lo/kwVYc3FOrrIBhA1vLWwKBq1NxaZBvFDcq7t57kfJan2B/g0fV3zYBdrdFfsbw
qzdDJSCoqr5LMucKJYQDJX9W4XODpSZFOGPcm7hd3mr7jMl6ysEHCXUDzOzYDw4w
tKYMj6Y8+Ad6n7pWKNh2AqcfYF3FoXTm9Y0nprN0HrLkqVRnJKWwz4PTSAN25tdN
/JTt8lARs1ngXwR2KzfU
=1FhT
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Eugene Birukov via lldb-dev]

Yes, that's exactly what I see, thanks a lot!
Does it explain why I see SIGILL reappear when I let process continue after 
mmap execution? I.e. do I need to look into this more?
Thanks,Eugene
> From: lab...@google.com
> Date: Thu, 8 Oct 2015 09:13:37 +0100
> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> InferiorCallMmap
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org; jing...@apple.com
> 
> Hi,
> 
> I believe the SIGILL problem you are referring to is the problem
> described in bug . This
> was fixed in r244875, but unfortunately, this was after 3.7 branch so
> this patch did not make it there. I recommend to try the master
> branch, I think this should work for you now (and do let me know if
> the problem persists).
> 
> pl
> 
> On 8 October 2015 at 00:20, Jim Ingham via lldb-dev
>  wrote:
> >
> >> 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 investigation is on 
> >> me, since I cannot share my program.
> >>
> >> But I am not looking at this SIG_ILL yet. Whatever the problem is with 
> >> mmap - the client must not carry this signal past expression evaluation. 
> >> I.e. I believe that we can construct any arbitrary function that causes 
> >> signal, call it from evaluate expression, and then continue would fail. I 
> >> suspect that this problem might be applicable to any POSIX platform.
> >
> > It doesn't happen on OS X, though when it comes to signal handling in the 
> > debugger OS X is an odd fish...
> >
> >>
> >> As it turned out, my initial analysis was incorrect. m_resume_signal is 
> >> calculated from StopInfo::m_value (now I wonder why do we need two fields 
> >> for that?).
> >
> > The signal that you stop with is not necessarily the one you are going to 
> > resume with.  For instance, if you use "process handle SIG_SOMESIG -p 0" to 
> > tell lldb not to propagate the signal, then the resume signal will be 
> > nothing, even though the stop signal is SIG_SOMESIG.
> >
> >> And after mmap call, m_stop_info on the thread is null. So, my current 
> >> theory is that there is an event with SIG_ILL that is stuck in the 
> >> broadcaster and is picked up and processed much later.
> >
> > When the expression evaluation completes, the StopInfo from the last 
> > "natural" stop should be put back in place in the thread.  After all, if 
> > you hit a breakpoint, run an expression, then ask why that thread stopped, 
> > you want to see "hit a breakpoint" not "ran a function call".  Sounds like 
> > that is failing somehow.
> >
> > Jim
> >
> >
> >>
> >> > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> >> > InferiorCallMmap
> >> > From: jing...@apple.com
> >> > Date: Wed, 7 Oct 2015 15:08:18 -0700
> >> > CC: lldb-dev@lists.llvm.org
> >> > To: eugen...@hotmail.com
> >> >
> >> > 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 whatever we do we're implementing it consistently.
> >> >
> >> > Jim
> >> >
> >> >
> >> >
> >> > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
> >> > >  wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > I am using LLDB 3.7.0 C++ API. My program stops at a certain 
> >> > > breakpoint and if I call SBFrame::EvaluateExpression() there, when I 
> >> > > let it go it terminates with SIG_ILL on an innocent thread. I dug up 
> >> > > into this, and there seems to be two independent problems there, this 
> >> > > mail is about the second one.
> >> > >
> >> > > • EvaluateExpression() calls Process::CanJIT() which in turn executes 
> >> > > mmap() on the inferior. This mmap gets SIG_ILL because execution 
> >> > > starts at address which is 2 bytes before the very first mmap 
> >> > > instruction. I am still looking why LLDB server decided to do that - I 
> >> > > am pretty sure that the client asked to set the program counter to 
> >> > > correct value.
> >> > > • So, the thread execution terminates and the signal is recorded on 
> >> > > Thread::m_resume_signal. This field is not cleared during 
> >> > > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the 
> >> > > program after breakpoint.
> >> > >
> >> > > So, what would be the best way to deal with the situation? Should I 
> >> > > add "resume signal" field to ThreadStateCheckpoint? Or would StopInfo 
> >> > > be a better place for that? Or something else?
> >> > >
> >> > > Thanks,
> >> > > Eugene
> >> > > ___
> >> > > lldb-dev mailing list
> >> > > lldb-dev@lists.l

Re: [lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?

[Greg Clayton via lldb-dev]

> On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi, 
> 
> I am writing a python script to set source line breakpoint in ObjC on Mac 
> OSX. But 
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
>  line) always fail. Any ideas?

As long as you have a selected target, this should work as long as you have 
debug info that matches.
> 
> Also, can I use full path instead of file basename?

Yes you can, but it must match exactly if you use the full path.

> In lldb, I found "b 
> /Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
>  will fail to bind but "b EATAnimatedView.m:21" will succeed. 

This is usually because you have a makefile build system that is creating debug 
info that doesn't contain a path that matches. When you launch a compiler, it 
can often end up with different paths than what you think you have. So set the 
breakpoint by basename first, then do:

(lldb) b main.c:12
Breakpoint 1: where = a.out`main + 70 at main.c:12, address = 0x00010b96
(lldb) breakpoint list --verbose
Current breakpoints:
1: file = 'main.c', line = 12
1.1: 
  module = /Volumes/work/gclayton/Documents/src/args/a.out
  compile unit = main.c
  function = main
  location = /Volumes/work/gclayton/Documents/src/args/main.c:12
  address = a.out[0x00010b96]
  resolved = false
  hit count = 0   


You will see the full path to your source file in the "location" value. You 
will probably notice that the path is different. We try to take care of 
removing and extra "../useless_dir" things from the paths and still make things 
match, but you might have a case that we aren't handling. Let me know what you 
see when you set the breakpoint by basename.


> Traceback (most recent call last):
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/chromedebugger.py",
>  line 69, in _generate_response
> params=message.get('params', {}),
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
>  line 42, in handle
> return self._domains[domain_name].handle(method_name, params)
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
>  line 106, in handle
> return self._handlers[method](params)
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
>  line 56, in _handler_wrapper
> ret = func(self, params)
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
>  line 248, in setBreakpointByUrl
> int(params['lineNumber']) + 1)
>   File 
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
>  line 283, in _set_breakpoint_by_filespec
> breakpoint = 
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation(filespec, line)
>   File 
> "/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py",
>  line 8650, in BreakpointCreateByLocation
> return _lldb.SBTarget_BreakpointCreateByLocation(self, *args)
> NotImplementedError: Wrong number of arguments for overloaded function 
> 'SBTarget_BreakpointCreateByLocation'.
>   Possible C/C++ prototypes are:
> BreakpointCreateByLocation(lldb::SBTarget *,char const *,uint32_t)
> BreakpointCreateByLocation(lldb::SBTarget *,lldb::SBFileSpec const 
> &,uint32_t)
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25111] New: SBThread::StepOut erases stack frames and doesn't set return value

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25111

Bug ID: 25111
   Summary: SBThread::StepOut erases stack frames and doesn't set
return value
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: beryku...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15035
  --> https://llvm.org/bugs/attachment.cgi?id=15035&action=edit
C++ source with a simple function that returns a value

SBThread::StepOut doesn't seem to work for me on lldb 3.8 compiled from trunk.
When I use it, the thread loses it's stack frames (len(thread.frames) == 0) and
the return_value attribute doesn't get set. What is curious though, that when I
print the thread, it's description contains both the stack frame and the return
value (in text form). I've attached a simple C++ program that demonstrates
this. I've compiled it with -g, -O0 and even -fno-inline-small-functions, so
the function should not be inlined.

import lldb
import os
import time

debugger = lldb.SBDebugger.Create()
target = debugger.CreateTarget("./test")
target.BreakpointCreateByLocation("test.cpp", 3)
process = target.LaunchSimple([], [], os.getcwd())

time.sleep(2) # wait for BP to be hit

thread = process.GetSelectedThread()
thread.StepOut()

time.sleep(2) # wait for step out to complete

value = thread.GetStopReturnValue() # No value

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 when a breakpoint hit is coincident with another 
> breakpoint (in my case I ran into this with both the jit breakpoint and the 
> gdb_image_notifier breakpoint). I turned on logging and saw:
> 
> Process::PerfomAction returning from action with m_should_stop: 1
> Process::PerfomAction returning from action with m_should_stop: 0
> 
> so I added the breakpoint id to the log to figure out which breakpoint was 
> causing the stop:
> 
> Process::PerfomAction returning from action at id -1 with m_should_stop: 1
> Process::PerfomAction returning from action at id 2 with m_should_stop: 0
> 
> where -1 is the JIT breakpoint. Any ideas why this might be happening? 
> Looking through the rest of the log, I never see the message about 
> Process::PerfomAction when -1 only is hit (though always when only 2 is hit). 
> Is the second breakpoint somehow forcing PerformAction to be called on all of 
> them even though it shouldn't be?

The way the breakpoint actions are designed to work, when there is more than 
one breakpoint at the stop address, is that ALL the actions get to run 
regardless of their return value, then if all the actions want to continue the 
process, it continues, but if any one of them wants to stop, then it will stop. 
 That seemed the most reasonable way to do it because you can reinstate a 
denied request to continue by manually continuing, but you can't reinstate a 
denied request to stop if you are already running.  It also seems best to let 
all the actions run if possible, since otherwise any accounting they want to do 
will get off.

Note, you can currently override this if you want to by calling 
SBProcess::Continue in your callback, since that will restart the process, and 
then the subsequent actions won't be able to run.  That means that which 
actions get to run and which get preempted is dependent on the order that lldb 
happens to run the actions, which is kind of gross.  This is really an accident 
not a feature, and at some point I'll get around to making 
"SBProcess::Continue" in the context of a breakpoint command only request the 
continue, so then it would all be deterministic.  

If there's sufficient demand for a breakpoint action to force the continue, we 
could add machinery to do that, but I don't think that should be the default 
behavior.

I haven't looked at the code that handles hitting the JIT breakpoint, but it is 
probably having the action return should_stop = 1 because it is assuming some 
code that is going to get triggered after the breakpoint decides to stop will 
restart if appropriate.  But I can't guess off the top of my head why having 
another breakpoint that didn't want to stop would defeat this.

Jim

> 
> Keno
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 the 
> segments with the same line number into one location, you'd make a location 
> per segment but treat them as a cluster, where a hit on one location in the 
> cluster would set a flag telling you to auto-continue the other locations in 
> the cluster till "something happened to reset the cluster".  You'd have to 
> figure out good heuristics for that "something happened".  You could probably 
> get away with "frame changed" and "hit the location that I hit the first time 
> I hit the cluster".  But I'd have to think a bit harder about this to assure 
> myself this was good enough.  And you'd have to keep a side table of history 
> for each breakpoint which you'd have to manage...  Nothing impossible, but it 
> didn't seem worth the effort at the time.
> 
> Anyway, if you are sufficiently motivated to give this a try, it would be a 
> more general solution to the problem without requiring user intervention - 
> either having to press continue some undetermined number of times, or create 
> the breakpoints with some special option.

BTW, Greg points out that one could teach the Thread Plans to treat step over a 
source line that has a breakpoint on it to do this job as well.  That will save 
you from having to store history information off to one side.  This approach 
might be worth pursuing, though I bet it will end up being trickier than it 
seems at first glance...

Jim


> 
>> 
>>> The motivation is that compilers in general and certainly clang in 
>>> particular love to put multiple line table entries in for a given line that 
>>> are either contiguous or interrupted by artificial book-keeping code.  So 
>>> if we didn???t coalesce these line entries, when you set a breakpoint on 
>>> such a line, you??d have to hit continue some unpredictable number of 
>>> times before you actually get past that line.  You could figure out how 
>>> many time by counting the number of locations, but nobody could be expected 
>>> to do that???  And if you are chasing multiple hits of the breakpoint 
>>> through code it was really a pain since one ???continue??? didn???t result 
>>> in one pass through the function containing the code. This happens very 
>>> frequently and was a font of bugs for lldb early on.
>> 
>> Understood - we get reports like this all the time, and I've also thought of
>> ways to workaround it, but for each idea I had, I could always find a way to
>> break it.  So now I tell users it "works as designed", and that it's better
>> to hit a BP a couple times than none at all.
>> 
>>> Note, this doesn???t affect the stepping algorithms, since when we step we 
>>> just look at where we land and if it has the same line number as we were 
>>> stepping through we keep going.  Of course, it also makes stepping over 
>>> such a line annoying for the same reason that it made continue annoying...
>> 
>> What about tail recursion?  You must at least check the stack ptr, no?
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev