Thanks, Matthew.
I'll have a look at Shawn's changes and get them in after reviewing.
On Tue, Sep 30, 2014 at 11:43 PM, Matthew Gardiner <m...@csr.com> wrote:
> Hi Shawn,
>
> It would be great for you to fix this and all the other lldb prompt
> bugs! Yes, lldb's rotten prompt it bothers me as much as you.
>
> My main problem with this issue, is that I am consuming all my time with
> trying to get CSRs kalimba chips debuggable by lldb. Particularly
> troublesome being those variants with non-8-bit bytes... I wish I could
> spend more this bug, but at the moment it is a peripheral concern for
> me.
>
> I have no pride associated with any previous fixes/bodges
> (sleeps/m_first_stop etc.) that I've done to "address" this issue. So
> please feel free to solve this exactly as you feel fit.
>
> I'm guessing that Todd is in a much closer time-zone to you, so it may
> be better if he applies any of your patches for you. Sorry Todd!
>
> thanks for the update
> Matt
>
> On Mon, 2014-09-29 at 15:36 -0700, Shawn Best wrote:
> > Hi All,
> >
> >
> > I have spent some time digging into this again and understand it a
> > little better now.
> >
> >
> > Matt, the reason your patch hangs on TestHello world, is because the
> > test script is launching the inferior program first then has lldb do
> > an attach. This is a different code path than a regular launch. The
> > one-shot you put in there for 'm_first_stop' to prevent it from
> > broadcasting the first stop, causes it to never get restarted.
> >
> >
> > On OSX, the application is launched first and then lldb attaches to
> > it. There is also a private stop message generated. The reason it is
> > not broadcast, is because of a special class member
> > 'm_resume_requested' and some special machinery ( class
> > AttachCompletionHandler : public NextEventAction ) that is used in the
> > case of launching to set it.
> >
> >
> > I could create a similar class "LaunchCompletionHandler" and get that
> > working to prevent the stop message from being broadcast.
> >
> >
> > The simplest solution is still my original 2 line fix.
> >
> >
> > I would like to get this fixed as it bothers me every time I see the
> > extra spew when debugging. There were also some unit tests failing on
> > linux that this patch fixed.
> >
> >
> > Shawn.
> >
> >
> >
> >
> > On Mon, Aug 18, 2014 at 3:08 AM, Matthew Gardiner <m...@csr.com>
> > wrote:
> > Hi Shawn,
> >
> > Have you spent anymore time looking at this prompt issue
> > (where you see the (lldb) prompt even when you use "process
> > launch")? I tried fixing it with the attached patch. This
> > fixes the issue fine at the lldb command line, but results in
> > the python TestHelloWorld test hanging the call to
> > Process::WaitForProcessToStop. I wondered if you had spent
> > anymore time on this lately and knew of a complete/better
> > fix...
> >
> > thanks
> > Matt
> >
> >
> > Greg Clayton wrote:
> > Jim and I have discussed the right thing to do which
> > we plan to implement as soon as we get the chance.
> >
> > Current we have two process states: public and
> > private. The private state is always up to date and is
> > used to track what the process is currently doing. The
> > public state gets set when we believe the end user
> > should see an event that will update the GUI or TTY
> > with the current state if needed (stopped or exited).
> > There is a lot of tricky code that uses the private
> > process state to manage things like the thread plans.
> > Things like source level single step might involve
> > starting and stopping and hitting breakpoints and
> > single instruction stepping, but the user only wants
> > to see the final eStateStopped when the source level
> > step is done. Expressions are also tricky, the public
> > state of the process is stopped, but when we run an
> > expression, we might resume the process many times and
> > the user will always see that the public state if
> > stopped. Internally though the thread plans are doing
> > a whole bunch of stuff to the process and the user
> > never hears anything about these (no events go
> > public).
> >
> > So the current public and private stuff uses
> > broadcaster hijacking and all sorts of other tricks to
> > avoid letting the end user know about the starts and
> > stops that they shouldn't know about. We eventually
> > want to have a new class, lets call in
> > lldb_private::ProcessState for now, that manages the
> > current process state and always receives the process
> > events. There would be no more public and private
> > events. We would have one version of the ProcessState
> > subclass that would cause the GUI/TTY to update
> > (replacing the public events) and one ProcessState
> > subclass that would manage running thread plans. There
> > would be stack of these and this will help us avoid
> > the whole public/private/hijacking stuff we have now.
> >
> > Launching a process would end up pushing a new
> > ProcessState class that could handle all the necessary
> > starts and stop we need to get the process to a
> > quiescent state that is presentable to the user. The
> > ProcessState subclass could eat all the events it
> > needs to while launching and then propagate the
> > stopped or running event when it gets popped off the
> > stack.
> >
> > So we should make some simple fixes for now to work
> > around the issue and get things working, but it would
> > also be great to get the new system up and running so
> > we can make this easier in the future for people that
> > want to make changes.
> >
> > Greg
> >
> >
> > On Aug 8, 2014, at 1:08 AM, Matthew Gardiner
> > <m...@csr.com> wrote:
> >
> > Folks,
> >
> > Regarding "launching using the shell", I
> > don't think applies in the buggy case that
> > myself and Shawn are looking at.
> >
> > I do:
> >
> > (lldb) target create ./test
> > ...
> > (lldb) process launch
> > ...
> >
> > and when I inspected the call to exec, I see
> > that my exe name is the program passed.
> >
> > Thanks for the insight into the broadcasting
> > of stop events. That explains why I see in the
> > ShouldBroadcastEvent, the ShouldStop and
> > ShouldReportStop calls.
> >
> > However, it would be nice to know if the first
> > stop event should be broadcast for "process
> > launch". I think it's an implementation
> > detail, and therefore should not. That would
> > help to fix this issue.
> >
> > However, Shawn's original suggestion to fix
> > this issue circumvents the above debate, by
> > replacing the call of HandlePrivateEvent with
> > SetPublicState. So which fix is best? Calling
> > SetPublicState rather than HandlePrivateEvent
> > is certainly more expedient, and avoids this
> > debate... but is it more
> > portable/future-proof?
> >
> > Matt
> >
> >
> > jing...@apple.com wrote:
> > If you are launching using the shell,
> > you'll see more stops before you get
> > to the executable you are actually
> > trying to launch. In that case,
> > instead of just running the binary
> > directly you effectively do:
> >
> > /bin/bash exec <binary> arg1 arg2
> >
> > so that you can get bash (or whatever
> > is set in $SHELL) to do the argument
> > expansion for you.
> > GetResumeCountForLaunchInfo calculates
> > this, then it is stuffed into the
> > ProcessLaunchInfo (SetResumeCount).
> > On Mac OS X we always let the Platform
> > launch, then attach, so in that case
> > the AttachCompletionHandler does the
> > extra resumes. I'm not all that
> > familiar with how the Linux side work,
> > but it also seems to use the
> > ProcessLaunchInfo's resume count.
> >
> > Note that in general in lldb not all
> > publicly broadcast stop messages are
> > going to result in a stop. For
> > instance, all the breakpoint command &
> > condition handling goes on as a result
> > of the broadcast of the public stop
> > event, but the process might just turn
> > around an continue based on that.
> > Whether to suppress the broadcast and
> > continue from the private state thread
> > or broadcast the event and let the
> > upper levels of lldb take care of what
> > happens from there on really depends
> > on where it makes sense to handle the
> > stop. So for the case of breakpoint
> > stops (or stop hooks, another
> > example), those end up being
> > equivalent to user typed commands,
> > just done for the user automatically
> > by the system. So having them happen
> > in a world where the public state
> > wasn't sync'ed up to the private state
> > ended up being very awkward.
> >
> > I haven't looked at the launching code
> > in detail recently so I am not sure
> > whether it makes sense for the first
> > stop to be handled as it is.
> >
> > Jim
> >
> >
> > On Aug 7, 2014, at 6:29 AM,
> > Matthew Gardiner
> > <m...@csr.com> wrote:
> >
> > Hi Shawn,
> >
> > I spent some time today
> > looking at how to arrange for
> > ShouldBroadcast to return
> > false for this first stop. I
> > managed to produce a quick
> > hack for this (i.e. just
> > counted the number of stops),
> > but due to other distractions
> > (from the rest of my job) I
> > didn't get that far into
> > discovering a nice way of
> > achieving this...
> >
> > What I did discover is that
> > with my build just doing
> > "process launch" results in 3
> > stops (and 3 private resumes).
> > That in itself I find
> > surprising, since I was under
> > the impression that I should
> > see the inferior stop just
> > once when exec is trapped by
> > PTRACE_ME.
> >
> > I then discovered that for
> > each of these 3 stops
> > ShouldBroadcast calls
> > Thread::ShouldStop, the
> > Thread::ShouldStop returns
> > true for the first stop and
> > false for the other 2. Looking
> > into these behaviour
> > differences I then found that
> > from within Thread::ShouldStop
> > we then call into the
> > following:
> >
> > StopInfoSP
> > private_stop_info
> > (GetPrivateStopInfo());
> > if (private_stop_info &&
> >
> private_stop_info->ShouldStopSynchronous(event_ptr) == false)
> > {
> >
> > and also
> >
> > bool over_ride_stop =
> >
> current_plan->ShouldAutoContinue(event_ptr);
> >
> > the results from either of
> > these, it seems providing the
> > reasoning behind the different
> > true/false returns. I'll
> > return to spend a bit more
> > time on this tomorrow. Let me
> > know if you get any further on
> > a similar vein!
> >
> > thanks
> > Matt
> >
> >
> >
> > Shawn Best wrote:
> > Matt,
> >
> > I think you are
> > probably right,
> > although there are
> > other places where it
> > directly calls
> > SetPublicState(). I
> > was wondering about
> > the possibility there
> > could be other
> > listeners waiting for
> > a broadcast public
> > Stop event. Is that a
> > possibility?
> >
> > Some others here were
> > investigating some
> > unit tests that were
> > failing intermittently
> > (StopHook). Their
> > description of the
> > problem sounds
> > unrelated to the
> > launch code, but this
> > patch also magically
> > fixes that.
> >
> > Shawn.
> >
> > On 8/6/2014 6:26 AM,
> > Matthew Gardiner
> > wrote:
> > Shawn,
> >
> > Like I said
> > earlier your
> > patch worked.
> > However I
> > think the
> > right fix is
> > to arrange
> > that
> > ShouldBroadcast
> returns false for this first stop. I believe this, because firstly no stops
> should be reported here since the user is only interested in launching a
> program, and additionally because it enables us to fix lldb without
> removing the call to HandlePrivateEvent. This, I think, is important to
> preserve as the central point for process state change handling.
> >
> > Matt
> >
> >
> >
> > Shawn Best
> > wrote:
> > Hi
> > Matthew,
> >
> > I have
> > also
> > been
> > tracking
> this bug. I believe there are other bugs in the unit tests failing
> indirectly because of this. I also have a patch that will fix it, but was
> sitting on it until the other one landed. These bugs do not show up on OSX
> since the inferiors are launched separately then attached to.
> >
> > The
> > first
> > odd
> > thing
> > the
> >
> launching code does is push an IOHandler when it sees the state transition
> to 'launching'. This is odd because I believe the launching program will
> always come up in a stopped state which will immediately pop the IOHandler.
> >
> > At
> > launch,
> the process comes up in the stopped state. The launch code manually calls
> HandlePrivateEvent() with the stop event, which then broadcasts the Event.
> When HandleProcessEvent gets the public stop, it dumps out the current
> thread state just as if an executing inferior hit a breakpoint and stopped.
> >
> > One
> > way to
> > fix
> > this
> > would
> > be:
> >
> > 1.
> > Don't
> > push
> > io
> > handler
> when state is 'launching'
> > 2.
> > Instead
> of manually calling HandlePrivateEvent, call SetPublicState().
> >
> >
> Alternately, we could try and debug why ShouldBroadcast() returns true,
> but that appears to be by design since it is expecting the public stop
> event to pop the IOHandler that had been pushed when launching.
> >
> > I have
> > attached
> a patch demonstrating this. In conjunction with the other patch for
> IOHandler race condition, it will fix a bunch of this kind of behaviour.
> >
> > Shawn.
> >
> > On
> > 8/5/2014
> 6:59 AM, Matthew Gardiner wrote:
> >
> Jim,
> >
> >
> I've been trying to debug an issue (I see it on 64-bit linux) where, I do
> "target create" and "process launch" and despite not requesting *stop at
> entry*, the first stop (which I believe is just the initial ptrace attach
> stop) is reported to the lldb command line. I added some fprintf to
> Process::HandlePrivateEvent, which counts the number of eStoppedState
> events seen and whether ShouldBroadcastEvent returns true for this event.
> Here's the output from my program with diagnostic:
> >
> >
> (lldb) target create ~/me/i64-hello.elf
> >
> Current executable set to '~/me/i64-hello.elf' (x86_64).
> >
> (lldb) process launch
> >
> MG Process::HandlePrivateEvent launching stopped_count 0 should_broadcast 1
> >
> Process 31393 launching
> >
> MG Process::HandlePrivateEvent stopped stopped_count 1 should_broadcast 1
> >
> MG Process::HandlePrivateEvent running stopped_count 1 should_broadcast 1
> >
> Process 31393 launched: 'i64-hello.elf' (x86_64)
> >
> Process 31393 stopped
> >
> * thread #1: tid = 31393, 0x0000003675a011f0, name = 'i64-hello.elf', stop
> reason = trace
> >
> >
> frame #0: 0x0000003675a011f0
> >
> -> 0x3675a011f0: movq %rsp, %rdi
> >
> 0x3675a011f3: callq 0x3675a046e0
> >
> 0x3675a011f8: movq %rax, %r12
> >
> 0x3675a011fb: movl 0x21eb97(%rip), %eax
> >
> (lldb) MG Process::HandlePrivateEvent stopped stopped_count 2
> should_broadcast 0
> >
> MG Process::HandlePrivateEvent running stopped_count 2 should_broadcast 0
> >
> MG Process::HandlePrivateEvent stopped stopped_count 3 should_broadcast 0
> >
> MG Process::HandlePrivateEvent running stopped_count 3 should_broadcast 0
> >
> >
> In summary, lldb reports the inferior to be stopped (even though
> /proc/pid/status and lldb "target list" say it is running). Clearly this is
> wrong (hence my earlier post).
> >
> >
> Am I correct in assuming that when ShouldBroadcastEvent returns true this
> means that lldb should show this event to the debug user? (And thus hide
> other events where ShouldBroadcastEvent=false).
> >
> >
> What puzzled me was why ShouldBroadcastEvent return true for this very
> first stop. Is this a bug?
> >
> >
> I also spent sometime at ShouldBroadcastEvent and saw that this:
> >
> >
> >
> case eStateStopped:
> >
> >
> case eStateCrashed:
> >
> >
> case eStateSuspended:
> >
> > {
> >
> ....
> >
> >
> if (was_restarted || should_resume || m_resume_requested)
> >
> > {
> >
> >
> evaluates as false, and hence the PrivateResume code is not called... does
> this seem buggy to you for this very first stop?
> >
> >
> I thought I'd try asking you, since in a previous mail from Greg, he cited
> you as being a thread-plan expert. (Hope that's ok!). I'd really appreciate
> your help in clarifying the above questions for me, and if you have time,
> giving me some ideas as to how to trace this one further e.g. how
> m_thread_list.ShouldStop and m_thread_list.ShouldReportStop should behave,
> etc.
> >
> >
> thanks for your help
> >
> Matt
> >
> >
> Matthew Gardiner wrote:
> >
> Folks,
> >
> >
> In addition to the overlapping prompt race Shawn Best and myself are
> looking at, I'm seeing another issue where if I launch a process, I get a
> stop (presumably the in) being reported to the UI.
> >
> >
> (lldb) target create ~/mydir/i64-hello.elf
> >
> Current executable set to '~/mydir/i64-hello.elf' (x86_64).
> >
> (lldb) process launch
> >
> Process 27238 launching
> >
> Process 27238 launched: '64-hello.elf' (x86_64)
> >
> Process 27238 stopped
> >
> * thread #1: tid = 27238, 0x0000003675a011f0, name = 'i64-hello.elf'
> >
> >
> frame #0:
> >
> (lldb) target list
> >
> Current targets:
> >
> * target #0: i64-hello.elf ( arch=x86_64-unknown-linux,
> platform=host, pid=27238, state=running )
> >
> (lldb)
> >
> >
> As you can see the "target list" reflects that the process is
> running. Which I confirmed by looking at /proc/27238/status.
> >
> >
> Anyone else seeing this?
> >
> >
> thanks
> >
> Matt
> >
> >
> >
> >
> Member of the CSR plc group of companies. CSR plc registered in
> England and Wales, registered number 4187346, registered office Churchill
> House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United
> Kingdom
> >
> More information can be found at www.csr.com <http://www.csr.com>.
> Keep up to date with CSR on our technical blog, www.csr.com/blog <
> http://www.csr.com/blog>, CSR people blog, www.csr.com/people <
> http://www.csr.com/people>, YouTube, www.youtube.com/user/CSRplc <
> http://www.youtube.com/user/CSRplc>, Facebook,
> www.facebook.com/pages/CSR/191038434253534 <
> http://www.facebook.com/pages/CSR/191038434253534>, or follow us on
> Twitter at www.twitter.com/CSR_plc <http://www.twitter.com/CSR_plc>.
> >
> New for 2014, you can now access the wide range of products powered
> by aptX at www.aptx.com <http://www.aptx.com>.
> >
> _______________________________________________
> >
> lldb-dev mailing list
> >
> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
> >
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> To report this email as spam click
> https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj!GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==
> <
> https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj%21GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==>
> .
> >
> _______________________________________________
> >
> lldb-dev mailing list
> >
> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
> >
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@cs.uiuc.edu
> >
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> >
>
>
>
--
Todd Fiala | Software Engineer | tfi...@google.com
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
