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

[Pavel Labath via lldb-dev]

Hi Jeffrey,

I see a couple of problems with the way you are using the lldb's API.
The main problem is you are launching the target via the command-line
API, which does not allow you to specify the listener upon creation.
When you start it this way all events go to the default debugger
listener (debugger.GetListener()), and by the time you connect your
own listener, some of these events have already been broadcast, and
that is why you get nondeterministic behavior. You should use the
SBTarget.Launch function to specify the listener from the start.

The second problem is the handling of the Stopped events. Sometimes
LLDB needs to stop the inferior do to some internal work, but this the
program is immediately resumed. This event is broadcast as a "stopped"
event with a special "restarted" bit set (see
SBProcess.GetRestartedFromEvent, and
)

hope that helps,
pl



On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> On mac OS, I am having difficulty understanding the launch debugger events
> sequence of lldb. I used the following code to play around LLDB. I found,
> for some binaries, debugger will enter stopped/paused mode, waiting for my
> further input, print stack shows:
> dbg> bt
> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> const*) + 1
>   * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> unsigned int, dyld_image_info const*) + 1
> frame #1: 0x401d
>
> But some other binaries, it just print "Process event: stopped, reason: 1"
> and inferior just exits immediately without waiting for debugger's further
> input.
>
> Questions:
> 1. When I launch a binary, is there supposed to be a loader breakpoint
> waiting for debugger continue? Any other debug events do I expect to get and
> continue?
> 2. What about attach?
> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
> happen for some binary but not others?
>
> Thanks for any information!
>
> # Should be first for LLDB package to be added to search path.
> from find_lldb import lldb
> from lldb import eStateStepping, eStateRunning, eStateExited, SBBreakpoint,
> SBEvent, SBListener, SBProcess, SBTarget
> import sys
> import os
> import subprocess
> from sys import stdin, stdout
> from threading import Thread
>
> class LLDBListenerThread(Thread):
> should_quit = False
>
> def __init__(self, process):
>   Thread.__init__(self)
>   self.listener = SBListener('Chrome Dev Tools Listener')
>   self._add_listener_to_process(process)
>   self._broadcast_process_state(process)
>   self._add_listener_to_target(process.target)
>
> def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = SBTarget.eBroadcastBitBreakpointChanged |
> SBTarget.eBroadcastBitWatchpointChanged |
> SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
>
> def _add_listener_to_process(self, process):
> # Listen for process events (Start/Stop/Interrupt/etc).
> broadcaster = process.GetBroadcaster()
> mask = SBProcess.eBroadcastBitStateChanged
> broadcaster.AddListener(self.listener, mask)
>
> def _broadcast_process_state(self, process):
> state = 'stopped'
> if process.state == eStateStepping or process.state ==
> eStateRunning:
> state = 'running'
> elif process.state == eStateExited:
> state = 'exited'
> self.should_quit = True
> thread = process.selected_thread
> print 'Process event: %s, reason: %d' % (state,
> thread.GetStopReason())
>
> def _breakpoint_event(self, event):
> breakpoint = SBBreakpoint.GetBreakpointFromEvent(event)
> print 'Breakpoint event: %s' % str(breakpoint)
>
> def run(self):
> while not self.should_quit:
> event = SBEvent()
> if self.listener.WaitForEvent(1, event):
> if event.GetType() == SBTarget.eBroadcastBitModulesLoaded:
> print 'Module load: %s' % str(event)
> elif SBProcess.EventIsProcessEvent(event):
>
> self._broadcast_process_state(SBProcess.GetProcessFromEvent(event))
> elif SBBreakpoint.EventIsBreakpointEvent(event):
> self._breakpoint_event(event)
>
> def _interctive_loop(debugger):
> process = debugger.GetSelectedTarget().process
> event_thread = LLDBListenerThread(process)
> event_thread.start()
>
> while (True):
> stdout.write('dbg> ')
> command = stdin.readline().rstrip()
> if len(command) == 0:
> continue
> debugger.HandleCommand(command)
>
>
> def main():
> debugger = lldb.SBDebugger.Create()
>
> print('Wor

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

[Jeffrey.fudan via lldb-dev]

Great, this is very helpful, will give a try.
Btw: is there any threading requirement of lldb API? For example, are all the 
Apis must be called on the event thread or they are free to be called on any 
thread? I know windows debug API has some limitation on this.

Sent from my iPad

> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
> 
> Hi Jeffrey,
> 
> I see a couple of problems with the way you are using the lldb's API.
> The main problem is you are launching the target via the command-line
> API, which does not allow you to specify the listener upon creation.
> When you start it this way all events go to the default debugger
> listener (debugger.GetListener()), and by the time you connect your
> own listener, some of these events have already been broadcast, and
> that is why you get nondeterministic behavior. You should use the
> SBTarget.Launch function to specify the listener from the start.
> 
> The second problem is the handling of the Stopped events. Sometimes
> LLDB needs to stop the inferior do to some internal work, but this the
> program is immediately resumed. This event is broadcast as a "stopped"
> event with a special "restarted" bit set (see
> SBProcess.GetRestartedFromEvent, and
> )
> 
> hope that helps,
> pl
> 
> 
> 
> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>  wrote:
>> Hi,
>> 
>> On mac OS, I am having difficulty understanding the launch debugger events
>> sequence of lldb. I used the following code to play around LLDB. I found,
>> for some binaries, debugger will enter stopped/paused mode, waiting for my
>> further input, print stack shows:
>> dbg> bt
>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
>> const*) + 1
>>  * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
>> unsigned int, dyld_image_info const*) + 1
>>frame #1: 0x401d
>> 
>> But some other binaries, it just print "Process event: stopped, reason: 1"
>> and inferior just exits immediately without waiting for debugger's further
>> input.
>> 
>> Questions:
>> 1. When I launch a binary, is there supposed to be a loader breakpoint
>> waiting for debugger continue? Any other debug events do I expect to get and
>> continue?
>> 2. What about attach?
>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
>> happen for some binary but not others?
>> 
>> Thanks for any information!
>> 
>> # Should be first for LLDB package to be added to search path.
>> from find_lldb import lldb
>> from lldb import eStateStepping, eStateRunning, eStateExited, SBBreakpoint,
>> SBEvent, SBListener, SBProcess, SBTarget
>> import sys
>> import os
>> import subprocess
>> from sys import stdin, stdout
>> from threading import Thread
>> 
>> class LLDBListenerThread(Thread):
>>should_quit = False
>> 
>>def __init__(self, process):
>>  Thread.__init__(self)
>>  self.listener = SBListener('Chrome Dev Tools Listener')
>>  self._add_listener_to_process(process)
>>  self._broadcast_process_state(process)
>>  self._add_listener_to_target(process.target)
>> 
>>def _add_listener_to_target(self, target):
>># Listen for breakpoint/watchpoint events
>> (Added/Removed/Disabled/etc).
>>broadcaster = target.GetBroadcaster()
>>mask = SBTarget.eBroadcastBitBreakpointChanged |
>> SBTarget.eBroadcastBitWatchpointChanged |
>> SBTarget.eBroadcastBitModulesLoaded
>>broadcaster.AddListener(self.listener, mask)
>> 
>>def _add_listener_to_process(self, process):
>># Listen for process events (Start/Stop/Interrupt/etc).
>>broadcaster = process.GetBroadcaster()
>>mask = SBProcess.eBroadcastBitStateChanged
>>broadcaster.AddListener(self.listener, mask)
>> 
>>def _broadcast_process_state(self, process):
>>state = 'stopped'
>>if process.state == eStateStepping or process.state ==
>> eStateRunning:
>>state = 'running'
>>elif process.state == eStateExited:
>>state = 'exited'
>>self.should_quit = True
>>thread = process.selected_thread
>>print 'Process event: %s, reason: %d' % (state,
>> thread.GetStopReason())
>> 
>>def _breakpoint_event(self, event):
>>breakpoint = SBBreakpoint.GetBreakpointFromEvent(event)
>>print 'Breakpoint event: %s' % str(breakpoint)
>> 
>>def run(self):
>>while not self.should_quit:
>>event = SBEvent()
>>if self.listener.WaitForEvent(1, event):
>>if event.GetType() == SBTarget.eBroadcastBitModulesLoaded:
>>print 'Module load: %s' % str(event)
>>elif SBProcess.EventIsProcessEvent(event):
>> 
>> self._broadcast_process_state(SBProcess.GetProcessFromEvent(event))
>>elif SBBreakpoint.EventIsBreakpointEvent(event):
>>self._breakpoint_

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

[Jim Ingham via lldb-dev]

There is no requirement that the lldb API’s be called on a particular thread on 
OS X.  LLDB tries to be robust against being called from multiple threads 
simultaneously for the same debugger, but you can still make it fall over if 
you try hard, particularly if you allow multiple threads to restart the process 
you are debugging.  Running multiple SBDebuggers on separate threads works 
fine, that’s the mode Xcode uses, and we haven’t had problems with this in 
quite a while.

Jim

> On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev 
>  wrote:
> 
> Great, this is very helpful, will give a try.
> Btw: is there any threading requirement of lldb API? For example, are all the 
> Apis must be called on the event thread or they are free to be called on any 
> thread? I know windows debug API has some limitation on this.
> 
> Sent from my iPad
> 
>> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
>> 
>> Hi Jeffrey,
>> 
>> I see a couple of problems with the way you are using the lldb's API.
>> The main problem is you are launching the target via the command-line
>> API, which does not allow you to specify the listener upon creation.
>> When you start it this way all events go to the default debugger
>> listener (debugger.GetListener()), and by the time you connect your
>> own listener, some of these events have already been broadcast, and
>> that is why you get nondeterministic behavior. You should use the
>> SBTarget.Launch function to specify the listener from the start.
>> 
>> The second problem is the handling of the Stopped events. Sometimes
>> LLDB needs to stop the inferior do to some internal work, but this the
>> program is immediately resumed. This event is broadcast as a "stopped"
>> event with a special "restarted" bit set (see
>> SBProcess.GetRestartedFromEvent, and
>> )
>> 
>> hope that helps,
>> pl
>> 
>> 
>> 
>> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>>  wrote:
>>> Hi,
>>> 
>>> On mac OS, I am having difficulty understanding the launch debugger events
>>> sequence of lldb. I used the following code to play around LLDB. I found,
>>> for some binaries, debugger will enter stopped/paused mode, waiting for my
>>> further input, print stack shows:
>>> dbg> bt
>>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
>>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
>>> const*) + 1
>>> * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
>>> unsigned int, dyld_image_info const*) + 1
>>>   frame #1: 0x401d
>>> 
>>> But some other binaries, it just print "Process event: stopped, reason: 1"
>>> and inferior just exits immediately without waiting for debugger's further
>>> input.
>>> 
>>> Questions:
>>> 1. When I launch a binary, is there supposed to be a loader breakpoint
>>> waiting for debugger continue? Any other debug events do I expect to get and
>>> continue?
>>> 2. What about attach?
>>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
>>> happen for some binary but not others?
>>> 
>>> Thanks for any information!
>>> 
>>> # Should be first for LLDB package to be added to search path.
>>> from find_lldb import lldb
>>> from lldb import eStateStepping, eStateRunning, eStateExited, SBBreakpoint,
>>> SBEvent, SBListener, SBProcess, SBTarget
>>> import sys
>>> import os
>>> import subprocess
>>> from sys import stdin, stdout
>>> from threading import Thread
>>> 
>>> class LLDBListenerThread(Thread):
>>>   should_quit = False
>>> 
>>>   def __init__(self, process):
>>> Thread.__init__(self)
>>> self.listener = SBListener('Chrome Dev Tools Listener')
>>> self._add_listener_to_process(process)
>>> self._broadcast_process_state(process)
>>> self._add_listener_to_target(process.target)
>>> 
>>>   def _add_listener_to_target(self, target):
>>>   # Listen for breakpoint/watchpoint events
>>> (Added/Removed/Disabled/etc).
>>>   broadcaster = target.GetBroadcaster()
>>>   mask = SBTarget.eBroadcastBitBreakpointChanged |
>>> SBTarget.eBroadcastBitWatchpointChanged |
>>> SBTarget.eBroadcastBitModulesLoaded
>>>   broadcaster.AddListener(self.listener, mask)
>>> 
>>>   def _add_listener_to_process(self, process):
>>>   # Listen for process events (Start/Stop/Interrupt/etc).
>>>   broadcaster = process.GetBroadcaster()
>>>   mask = SBProcess.eBroadcastBitStateChanged
>>>   broadcaster.AddListener(self.listener, mask)
>>> 
>>>   def _broadcast_process_state(self, process):
>>>   state = 'stopped'
>>>   if process.state == eStateStepping or process.state ==
>>> eStateRunning:
>>>   state = 'running'
>>>   elif process.state == eStateExited:
>>>   state = 'exited'
>>>   self.should_quit = True
>>>   thread = process.selected_thread
>>>   print 'Process event: %s, reason: %d' % (state,
>>> thread.GetStopReason())
>>> 
>>>   def _breakpoint_event(self, event):
>>>

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

[Jeffrey Tan via lldb-dev]

Thanks Jim. Is this true for other platforms? Our IDE is going to support
Mac and Linux and may extend to Windows some time later.
Just curious, why does Xcode create multiple SBDebuggers assuming it is
debugging a single process? Are you talking about multiple-processes
scenario(One SBDebugger for one process)?


On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:

> There is no requirement that the lldb API’s be called on a particular
> thread on OS X.  LLDB tries to be robust against being called from multiple
> threads simultaneously for the same debugger, but you can still make it
> fall over if you try hard, particularly if you allow multiple threads to
> restart the process you are debugging.  Running multiple SBDebuggers on
> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
> problems with this in quite a while.
>
> Jim
>
> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Great, this is very helpful, will give a try.
> > Btw: is there any threading requirement of lldb API? For example, are
> all the Apis must be called on the event thread or they are free to be
> called on any thread? I know windows debug API has some limitation on this.
> >
> > Sent from my iPad
> >
> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
> >>
> >> Hi Jeffrey,
> >>
> >> I see a couple of problems with the way you are using the lldb's API.
> >> The main problem is you are launching the target via the command-line
> >> API, which does not allow you to specify the listener upon creation.
> >> When you start it this way all events go to the default debugger
> >> listener (debugger.GetListener()), and by the time you connect your
> >> own listener, some of these events have already been broadcast, and
> >> that is why you get nondeterministic behavior. You should use the
> >> SBTarget.Launch function to specify the listener from the start.
> >>
> >> The second problem is the handling of the Stopped events. Sometimes
> >> LLDB needs to stop the inferior do to some internal work, but this the
> >> program is immediately resumed. This event is broadcast as a "stopped"
> >> event with a special "restarted" bit set (see
> >> SBProcess.GetRestartedFromEvent, and
> >> )
> >>
> >> hope that helps,
> >> pl
> >>
> >>
> >>
> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
> >>  wrote:
> >>> Hi,
> >>>
> >>> On mac OS, I am having difficulty understanding the launch debugger
> events
> >>> sequence of lldb. I used the following code to play around LLDB. I
> found,
> >>> for some binaries, debugger will enter stopped/paused mode, waiting
> for my
> >>> further input, print stack shows:
> >>> dbg> bt
> >>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> >>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> >>> const*) + 1
> >>> * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> >>> unsigned int, dyld_image_info const*) + 1
> >>>   frame #1: 0x401d
> >>>
> >>> But some other binaries, it just print "Process event: stopped,
> reason: 1"
> >>> and inferior just exits immediately without waiting for debugger's
> further
> >>> input.
> >>>
> >>> Questions:
> >>> 1. When I launch a binary, is there supposed to be a loader breakpoint
> >>> waiting for debugger continue? Any other debug events do I expect to
> get and
> >>> continue?
> >>> 2. What about attach?
> >>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why
> does it
> >>> happen for some binary but not others?
> >>>
> >>> Thanks for any information!
> >>>
> >>> # Should be first for LLDB package to be added to search path.
> >>> from find_lldb import lldb
> >>> from lldb import eStateStepping, eStateRunning, eStateExited,
> SBBreakpoint,
> >>> SBEvent, SBListener, SBProcess, SBTarget
> >>> import sys
> >>> import os
> >>> import subprocess
> >>> from sys import stdin, stdout
> >>> from threading import Thread
> >>>
> >>> class LLDBListenerThread(Thread):
> >>>   should_quit = False
> >>>
> >>>   def __init__(self, process):
> >>> Thread.__init__(self)
> >>> self.listener = SBListener('Chrome Dev Tools Listener')
> >>> self._add_listener_to_process(process)
> >>> self._broadcast_process_state(process)
> >>> self._add_listener_to_target(process.target)
> >>>
> >>>   def _add_listener_to_target(self, target):
> >>>   # Listen for breakpoint/watchpoint events
> >>> (Added/Removed/Disabled/etc).
> >>>   broadcaster = target.GetBroadcaster()
> >>>   mask = SBTarget.eBroadcastBitBreakpointChanged |
> >>> SBTarget.eBroadcastBitWatchpointChanged |
> >>> SBTarget.eBroadcastBitModulesLoaded
> >>>   broadcaster.AddListener(self.listener, mask)
> >>>
> >>>   def _add_listener_to_process(self, process):
> >>>   # Listen for process events (Start/Stop/Interrupt/etc).
> >>>   broadcaster = process.GetBroadcaster()
> >>>   m

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

[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, and also 
supports multiple debuggers running each one target or any combination.  Since 
each Debugger gets a separate script interpreter (and all its state) by running 
multiple processes in one SBDebugger you could offer users the possibility of 
having scripted commands to control a set of processes (e.g. hitting a 
breakpoint in one process could trigger actions in the other.)  It might be 
possible to do some interesting things that way.  

OTOH, keeping to one process per debugger is a much simpler programming model.  
So if you were planning to have YOUR code that runs the debugger handle the 
possible interactions among processes, then it is probably going to be easier 
to manage doing it that way.

Jim



> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan  wrote:
> 
> Thanks Jim. Is this true for other platforms? Our IDE is going to support Mac 
> and Linux and may extend to Windows some time later. 
> Just curious, why does Xcode create multiple SBDebuggers assuming it is 
> debugging a single process? Are you talking about multiple-processes 
> scenario(One SBDebugger for one process)? 
> 
> 
> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  > wrote:
> There is no requirement that the lldb API’s be called on a particular thread 
> on OS X.  LLDB tries to be robust against being called from multiple threads 
> simultaneously for the same debugger, but you can still make it fall over if 
> you try hard, particularly if you allow multiple threads to restart the 
> process you are debugging.  Running multiple SBDebuggers on separate threads 
> works fine, that’s the mode Xcode uses, and we haven’t had problems with this 
> in quite a while.
> 
> Jim
> 
> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Great, this is very helpful, will give a try.
> > Btw: is there any threading requirement of lldb API? For example, are all 
> > the Apis must be called on the event thread or they are free to be called 
> > on any thread? I know windows debug API has some limitation on this.
> >
> > Sent from my iPad
> >
> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  >> > wrote:
> >>
> >> Hi Jeffrey,
> >>
> >> I see a couple of problems with the way you are using the lldb's API.
> >> The main problem is you are launching the target via the command-line
> >> API, which does not allow you to specify the listener upon creation.
> >> When you start it this way all events go to the default debugger
> >> listener (debugger.GetListener()), and by the time you connect your
> >> own listener, some of these events have already been broadcast, and
> >> that is why you get nondeterministic behavior. You should use the
> >> SBTarget.Launch function to specify the listener from the start.
> >>
> >> The second problem is the handling of the Stopped events. Sometimes
> >> LLDB needs to stop the inferior do to some internal work, but this the
> >> program is immediately resumed. This event is broadcast as a "stopped"
> >> event with a special "restarted" bit set (see
> >> SBProcess.GetRestartedFromEvent, and
> >>  >> >)
> >>
> >> hope that helps,
> >> pl
> >>
> >>
> >>
> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
> >> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>> Hi,
> >>>
> >>> On mac OS, I am having difficulty understanding the launch debugger events
> >>> sequence of lldb. I used the following code to play around LLDB. I found,
> >>> for some binaries, debugger will enter stopped/paused mode, waiting for my
> >>> further input, print stack shows:
> >>> dbg> bt
> >>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> >>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> >>> const*) + 1
> >>> * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> >>> unsigned int, dyld_image_info const*) + 1
> >>>   frame #1: 0x401d
> >>>
> >>> But some other binaries, it just print "Process event: stopped, reason: 1"
> >>> and inferior just exits immediately without waiting for debugger's further
> >>> input.
> >>>
> >>> Questions:
> >>> 1. When I launch a binary, is there supposed to be a loader breakpoint
> >>> waiting for debugger continue? Any other debug events do I expect to get 
> >>> and
> >>> continue?
> >>> 2. What about attach?
> >>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
> >>> happen for some binary but not others?
> >>>
> >>> Thanks for any information!
> >>>
> >>> # Should be first for LLDB package to be 

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

[Jeffrey Tan via lldb-dev]

Jim/Pavel, my toy code works reliably after using SBListener with
SBTarget.Launch/Attach.
One thing I noticed is:
If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop
event of eStopReasonSignal at loader breakpoint. However
SBTarget.AttachXXX() will pause the target process without a stop event. Is
this expected? This may cause a bit state issue in our IDE since we rely on
the stop event from debugger to update UI in IDE. Is there any way to tell
lldb to emit a stop event during attach?


On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  wrote:

> 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, and
> also supports multiple debuggers running each one target or any
> combination.  Since each Debugger gets a separate script interpreter (and
> all its state) by running multiple processes in one SBDebugger you could
> offer users the possibility of having scripted commands to control a set of
> processes (e.g. hitting a breakpoint in one process could trigger actions
> in the other.)  It might be possible to do some interesting things that
> way.
>
> OTOH, keeping to one process per debugger is a much simpler programming
> model.  So if you were planning to have YOUR code that runs the debugger
> handle the possible interactions among processes, then it is probably going
> to be easier to manage doing it that way.
>
> Jim
>
>
>
> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan  wrote:
>
> Thanks Jim. Is this true for other platforms? Our IDE is going to support
> Mac and Linux and may extend to Windows some time later.
> Just curious, why does Xcode create multiple SBDebuggers assuming it is
> debugging a single process? Are you talking about multiple-processes
> scenario(One SBDebugger for one process)?
>
>
> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:
>
>> There is no requirement that the lldb API’s be called on a particular
>> thread on OS X.  LLDB tries to be robust against being called from multiple
>> threads simultaneously for the same debugger, but you can still make it
>> fall over if you try hard, particularly if you allow multiple threads to
>> restart the process you are debugging.  Running multiple SBDebuggers on
>> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
>> problems with this in quite a while.
>>
>> Jim
>>
>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Great, this is very helpful, will give a try.
>> > Btw: is there any threading requirement of lldb API? For example, are
>> all the Apis must be called on the event thread or they are free to be
>> called on any thread? I know windows debug API has some limitation on this.
>> >
>> > Sent from my iPad
>> >
>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
>> >>
>> >> Hi Jeffrey,
>> >>
>> >> I see a couple of problems with the way you are using the lldb's API.
>> >> The main problem is you are launching the target via the command-line
>> >> API, which does not allow you to specify the listener upon creation.
>> >> When you start it this way all events go to the default debugger
>> >> listener (debugger.GetListener()), and by the time you connect your
>> >> own listener, some of these events have already been broadcast, and
>> >> that is why you get nondeterministic behavior. You should use the
>> >> SBTarget.Launch function to specify the listener from the start.
>> >>
>> >> The second problem is the handling of the Stopped events. Sometimes
>> >> LLDB needs to stop the inferior do to some internal work, but this the
>> >> program is immediately resumed. This event is broadcast as a "stopped"
>> >> event with a special "restarted" bit set (see
>> >> SBProcess.GetRestartedFromEvent, and
>> >> )
>> >>
>> >> hope that helps,
>> >> pl
>> >>
>> >>
>> >>
>> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>> >>  wrote:
>> >>> Hi,
>> >>>
>> >>> On mac OS, I am having difficulty understanding the launch debugger
>> events
>> >>> sequence of lldb. I used the following code to play around LLDB. I
>> found,
>> >>> for some binaries, debugger will enter stopped/paused mode, waiting
>> for my
>> >>> further input, print stack shows:
>> >>> dbg> bt
>> >>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
>> >>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
>> >>> const*) + 1
>> >>> * frame #0: 0x7fff5fc0d2af
>> dyld`gdb_image_notifier(dyld_image_mode,
>> >>> unsigned int, dyld_image_info const*) + 1
>> >>>   frame #1: 0x401d
>> >>>
>> >>> But some other binaries, it just print "Process event: stopped,
>> reason: 1"
>> >>> and inferior just exits immediately without waiting for debugger'

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

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

Jim

> On Jan 29, 2016, at 11:50 AM, Jeffrey Tan  wrote:
> 
> Jim/Pavel, my toy code works reliably after using SBListener with 
> SBTarget.Launch/Attach. 
> One thing I noticed is:
> If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop event 
> of eStopReasonSignal at loader breakpoint. However SBTarget.AttachXXX() will 
> pause the target process without a stop event. Is this expected? This may 
> cause a bit state issue in our IDE since we rely on the stop event from 
> debugger to update UI in IDE. Is there any way to tell lldb to emit a stop 
> event during attach? 
> 
> 
> On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  > wrote:
> 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, and 
> also supports multiple debuggers running each one target or any combination.  
> Since each Debugger gets a separate script interpreter (and all its state) by 
> running multiple processes in one SBDebugger you could offer users the 
> possibility of having scripted commands to control a set of processes (e.g. 
> hitting a breakpoint in one process could trigger actions in the other.)  It 
> might be possible to do some interesting things that way.  
> 
> OTOH, keeping to one process per debugger is a much simpler programming 
> model.  So if you were planning to have YOUR code that runs the debugger 
> handle the possible interactions among processes, then it is probably going 
> to be easier to manage doing it that way.
> 
> Jim
> 
> 
> 
>> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan > > wrote:
>> 
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support 
>> Mac and Linux and may extend to Windows some time later. 
>> Just curious, why does Xcode create multiple SBDebuggers assuming it is 
>> debugging a single process? Are you talking about multiple-processes 
>> scenario(One SBDebugger for one process)? 
>> 
>> 
>> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham > > wrote:
>> There is no requirement that the lldb API’s be called on a particular thread 
>> on OS X.  LLDB tries to be robust against being called from multiple threads 
>> simultaneously for the same debugger, but you can still make it fall over if 
>> you try hard, particularly if you allow multiple threads to restart the 
>> process you are debugging.  Running multiple SBDebuggers on separate threads 
>> works fine, that’s the mode Xcode uses, and we haven’t had problems with 
>> this in quite a while.
>> 
>> Jim
>> 
>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev 
>> > mailto:lldb-dev@lists.llvm.org>> wrote:
>> >
>> > Great, this is very helpful, will give a try.
>> > Btw: is there any threading requirement of lldb API? For example, are all 
>> > the Apis must be called on the event thread or they are free to be called 
>> > on any thread? I know windows debug API has some limitation on this.
>> >
>> > Sent from my iPad
>> >
>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath > >> > wrote:
>> >>
>> >> Hi Jeffrey,
>> >>
>> >> I see a couple of problems with the way you are using the lldb's API.
>> >> The main problem is you are launching the target via the command-line
>> >> API, which does not allow you to specify the listener upon creation.
>> >> When you start it this way all events go to the default debugger
>> >> listener (debugger.GetListener()), and by the time you connect your
>> >> own listener, some of these events have already been broadcast, and
>> >> that is why you get nondeterministic behavior. You should use the
>> >> SBTarget.Launch function to specify the listener from the start.
>> >>
>> >> The second problem is the handling of the Stopped events. Sometimes
>> >> LLDB needs to stop the inferior do to some internal work, but this the
>> >> program is immediately resumed. This event is broadcast as a "stopped"
>> >> event with a special "restarted" bit set (see
>> >> SBProcess.GetRestartedFromEvent, and
>> >> > >> >)
>> >>
>> >> hope that helps,
>> >> pl
>> >>
>> >>
>> >>
>> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>> >> mailto:lldb-dev@lists.llvm.org>> wrote:
>> >>> Hi,
>> >>>
>> >>> On mac OS, I am having difficulty understanding the launch debugger 
>> >>> events
>> >>> sequence of lldb.

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

[Jeffrey Tan via lldb-dev]

Thanks. That's fine, just want to confirm the behavior and my
understanding. I can definitely deal with the difference between
attach/launch myself.

On Fri, Jan 29, 2016 at 1:41 PM, Jim Ingham  wrote:

> 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.
>
> Jim
>
> On Jan 29, 2016, at 11:50 AM, Jeffrey Tan  wrote:
>
> Jim/Pavel, my toy code works reliably after using SBListener with
> SBTarget.Launch/Attach.
> One thing I noticed is:
> If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop
> event of eStopReasonSignal at loader breakpoint. However
> SBTarget.AttachXXX() will pause the target process without a stop event. Is
> this expected? This may cause a bit state issue in our IDE since we rely on
> the stop event from debugger to update UI in IDE. Is there any way to tell
> lldb to emit a stop event during attach?
>
>
> On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  wrote:
>
>> 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, and
>> also supports multiple debuggers running each one target or any
>> combination.  Since each Debugger gets a separate script interpreter (and
>> all its state) by running multiple processes in one SBDebugger you could
>> offer users the possibility of having scripted commands to control a set of
>> processes (e.g. hitting a breakpoint in one process could trigger actions
>> in the other.)  It might be possible to do some interesting things that
>> way.
>>
>> OTOH, keeping to one process per debugger is a much simpler programming
>> model.  So if you were planning to have YOUR code that runs the debugger
>> handle the possible interactions among processes, then it is probably going
>> to be easier to manage doing it that way.
>>
>> Jim
>>
>>
>>
>> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan 
>> wrote:
>>
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support
>> Mac and Linux and may extend to Windows some time later.
>> Just curious, why does Xcode create multiple SBDebuggers assuming it is
>> debugging a single process? Are you talking about multiple-processes
>> scenario(One SBDebugger for one process)?
>>
>>
>> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  wrote:
>>
>>> There is no requirement that the lldb API’s be called on a particular
>>> thread on OS X.  LLDB tries to be robust against being called from multiple
>>> threads simultaneously for the same debugger, but you can still make it
>>> fall over if you try hard, particularly if you allow multiple threads to
>>> restart the process you are debugging.  Running multiple SBDebuggers on
>>> separate threads works fine, that’s the mode Xcode uses, and we haven’t had
>>> problems with this in quite a while.
>>>
>>> Jim
>>>
>>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > Great, this is very helpful, will give a try.
>>> > Btw: is there any threading requirement of lldb API? For example, are
>>> all the Apis must be called on the event thread or they are free to be
>>> called on any thread? I know windows debug API has some limitation on this.
>>> >
>>> > Sent from my iPad
>>> >
>>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  wrote:
>>> >>
>>> >> Hi Jeffrey,
>>> >>
>>> >> I see a couple of problems with the way you are using the lldb's API.
>>> >> The main problem is you are launching the target via the command-line
>>> >> API, which does not allow you to specify the listener upon creation.
>>> >> When you start it this way all events go to the default debugger
>>> >> listener (debugger.GetListener()), and by the time you connect your
>>> >> own listener, some of these events have already been broadcast, and
>>> >> that is why you get nondeterministic behavior. You should use the
>>> >> SBTarget.Launch function to specify the listener from the start.
>>> >>
>>> >> The second problem is the handling of the Stopped events. Sometimes
>>> >> LLDB needs to stop the inferior do to some internal work, but this the
>>> >> program is immediately resumed. This event is broadcast as a "stopped"
>>> >> event with a special "restarted" bit set (see
>>> >> SBProcess.GetRestartedFromEvent, and
>>> >> )
>>> >>
>>> >> hope that helps,
>>> >> pl
>>> >>
>>> >>
>>> >>
>>> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>>> >>  wrote:
>>> >>> Hi,
>>> >>>
>>> >>> On mac OS, I am having difficulty understanding the launch debugger
>>> events
>>> >>> sequence of lldb

[lldb-dev] Listening for thread events

[John Lindal via lldb-dev]

I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for
thread events.

lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose a
GetBroadcaster() event the way SBProcess does.

I wouldn't really want to have to listen to every SBThread object, but when
the program stops, I could listen to the selected thread.  (Getting the
events from SBProcess would also work, if Process relayed them.)

Is this a feature that has not yet been implemented?  I couldn't find any
related tickets in Bugzilla.

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

Re: [lldb-dev] Listening for thread events

[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 lldb, you can listen to 
individual broadcasters or “broadcaster event classes”.  You want to do the 
latter.

You get the event class name with the GetBroadcasterClassName method on the 
class you are interested in (SBThread in this case) and then on your listener 
call 

SBListener::StartListeningForEventClass

If you do that, the debugger will sign your listener up for the objects of that 
broadcaster class as they come and go.  That makes listening to events on all 
the threads in your process quite straightforward.

Hope this helps.

Jim


> On Jan 29, 2016, at 2:32 PM, John Lindal via lldb-dev 
>  wrote:
> 
> I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for 
> thread events.
> 
> lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose a 
> GetBroadcaster() event the way SBProcess does.
> 
> I wouldn't really want to have to listen to every SBThread object, but when 
> the program stops, I could listen to the selected thread.  (Getting the 
> events from SBProcess would also work, if Process relayed them.)
> 
> Is this a feature that has not yet been implemented?  I couldn't find any 
> related tickets in Bugzilla.
> 
> Thanks,
> John Lindal
> ___
> 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] Patch to fix REPL for ARMv7 & ARMv6 on linux

[William Dillon via lldb-dev]

Hi Omair,

In a very real sense, no information is lost here.  The addition of the ‘l’ 
only indicates that the system is little endian.  When the triple is created, 
the flag setting little endian is set (and defaults to little anyway).  There 
is no other valid ARM sub architecture with ARMv6 or ARMv7 that ends with an 
‘l’.

I based this change somewhat on the existing model for massaging LLVM triples 
such as in HostInfoLinux.cpp:

void
HostInfoLinux::ComputeHostArchitectureSupport(ArchSpec &arch_32, ArchSpec 
&arch_64)
{
HostInfoPosix::ComputeHostArchitectureSupport(arch_32, arch_64);

const char *distribution_id = GetDistributionId().data();

// On Linux, "unknown" in the vendor slot isn't what we want for the default
// triple.  It's probably an artifact of config.guess.
if (arch_32.IsValid())
{
arch_32.SetDistributionId(distribution_id);
if (arch_32.GetTriple().getVendor() == llvm::Triple::UnknownVendor)
arch_32.GetTriple().setVendorName(llvm::StringRef());
}
if (arch_64.IsValid())
{
arch_64.SetDistributionId(distribution_id);
if (arch_64.GetTriple().getVendor() == llvm::Triple::UnknownVendor)
arch_64.GetTriple().setVendorName(llvm::StringRef());
}
}

Would it make you more comfortable is this patch was rewritten within 
HostInfoLinux::ComputeHostArchitectureSupport alongside the massaging of the 
vendor name for linux?

- Will

> On Jan 27, 2016, at 1:28 AM, Omair Javaid  wrote:
> 
> Hi Will,
> 
> I dont understand REPL and thus the benefits it will have by making
> change to architecture name. I would not recommend to drop any
> information that we get from the host operating system.
> 
> LLDB maintains core information alongwith triple in ArchSpec, may be
> you can parse triple to reflect correct core and use core instead of
> architecture name where needed.
> 
> Kindly elaborate in a bit detail what are we getting out of this
> change for more accurate comments.
> 
> Thanks!
> 
> On 26 January 2016 at 14:47, Pavel Labath  wrote:
>> + Omair
>> 
>> I don't really understand arm (sub)-architectures or REPL. The patch
>> seems mostly harmless, but it also feels like a hack to me. A couple
>> of questions:
>> - why does this only pose a problem for REPL?
>> - If I understand correctly, the problem is that someone is looking at
>> the architecture string contained in the Triple, and not finding what
>> it expects. Is that so? Could you point me to (some of) the places
>> that do that.
>> 
>> Omair, any thoughts on this?
>> 
>> cheers,
>> pl
>> 
>> 
>> On 25 January 2016 at 18:55, Hans Wennborg  wrote:
>>> This patch looks reasonable to me, but I don't know enough about LLDB
>>> to actually review it.
>>> 
>>> +Renato or Pavel maybe?
>>> 
>>> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
>>>  wrote:
 Hi again, everyone
 
 I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
 merging it over is fairly straight-forward.
 
 Thanks in advance for your comments!
 - Will
 
> There is a small change that enables correct calculation of arm sub 
> architectures while using the REPL on arm-linux.  As you may of may or 
> may not know, linux appends ‘l’ to arm architecture versions to denote 
> little endian.  This sometimes interferes with the determination of the 
> architecture in the triple.  I experimented with adding sub architecture 
> entries for these within lldb, but I discovered a simpler (and less 
> invasive) method.  Because LLVM already knows how to handle some of these 
> cases (I have a patch submitted for review that enables v6l; v7l already 
> works), I am relying on llvm to clean it up.  The gist of it is that the 
> llvm constructor (when given a triple string) retains the provided string 
> unless an accessor mutates it.  Meanwhile, the accessors for the 
> components go through the aliasing and parsing logic.  This code detects 
> whether the sub-architecture that armv6l or armv7l aliases to is 
> detected, and re-sets the architecture in the triple.  This overwrites 
> the architecture that comes from linux, thus sanitizing it.
> 
> Some kind of solution is required for the REPL to work on arm-linux.  
> Without it, the REPL crashes.

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

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

[Jeffrey Tan via lldb-dev]

Hi,

Normally if you want to attach to a process you only have the pid/name of
the process. How do you get SBTarget? Am I supposed to call
SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
we require a dummy SBTarget before attaching? This seems to be a wrong
design to me... Thanks.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev