Re: [cdt-dev] Resuming from Shared Library Event

["Alain Magloire" <alain@xxxxxxx>]

Please use the cdt-dev-debug@xxxxxxxxxxx.

>
> Unfortunately, I think there are problems with that last step.

I believe you are right, the thread-id of the execution command
may be different then the thread-id of the shared library event
 
> It seems to me that in order to solve this, the initial part of Step 
> 3 needs to check to see if the current thread (and it really needs to 
> get the current thread in order to do this instead of relying on an 
> out-of-date cache) is the same as the one in which the Step Over, 
> Step Into, or Step Out operation was executed.  If so, then it needs 
> to restart that operation.  However, if the Shared Library event 
> takes place in a different thread, then that thread can just be 
> resumed with a Continue command.
> 

But this will not work, "continue" in gdb does not resume one thread
it continues the execution of the inferior so you've lost the context.

We should probably save the thread of the last execution and restore
the correct context before the resume/next/step/ etc ... 

> Anyway, I'm hoping that someone can examine my analysis and let me 
> know if I'm spot on or off the mark.  If the former, I'll file a bug 
> report and fix my local copy.  If the latter, then I'd appreciate 
> hearing what the correct fix would be.

Yes please PR a copy of this email for the description will be fine.

Thanks.

=========================
> I have a question about the processing of a Shared Library event, in 
> particular, what's happening in EventManager.processSharedLibEvent.
> 
> As I read it, the function can be broken down into three parts:
> 
> 1. Install any deferred breakpoints that reside in the just-loaded library.
> 
> 2. Determine how execution should be restarted, based on the user's 
> last action (that is, is the user doing a Step Into, Step Over, Step 
> Return, or Continue).
> 
> 3. Restart the application.
> 
> Unfortunately, I think there are problems with that last step.  If 
> Step 2 determined that it needed to restart a Continue command, then 
> that command is performed immediately.  However, for any other type 
> of restart, a lot of thread and stack munging takes place.  It seems 
> that we (attempt to) get the current thread, the ID of that that 
> thread, and the stack of the thread.  We then ask the debugged 
> process for the current stack level.  This stack level number is then 
> used to create a different stack level number assuming that counting 
> starts from the end of the stack other than what gdb assumes. 
> Finally, we select the "current" thread, select the stack frame, and 
> issue the command to restart the application.
> 
> I think that all that thread and stack setting takes place because 
> the proper context needs to be established in order to restart the 
> Step, Next, and Finish commands.  However, it doesn't seem to take 
> into account the possibility that the Shared Library event is taking 
> place in a different thread than the one in which the Step, Next, or 
> Finish command was issued in the first place.
> 
> Take the case I'm looking into right now.  My application has 64 
> threads, with the 63rd thread (with Thread ID #92) being one in which 
> I'm performing a Step Out operation.  Before that operation can 
> complete, Thread ID #1 loads a shared library, issuing a Shared 
> Library event.
> 
> Now, when processSharedLibEvent is called and tries to resume the 
> Step Out command, it gets the "current thread".  This query returns 
> an object referring to Thread ID #92 where I was doing the Step Out. 
> When that thread object is used to get the "current stack frame", it 
> returns a record indicating the function in which I issued the Step 
> Out command, which is in the 42nd stack frame record.  However, later 
> in the function, we query the debugged process for stack depth info. 
> This query indicates that the stack is only 5 levels deep, even 
> though I know it's at least 42 in the context of the Step Out 
> operation.  Adding some debugging code here, I see that gdb thinks 
> that the current thread is Thread ID #1, not Thread ID #92 that CDT 
> thinks it is. With this mixed up information, processSharedLibEvent 
> calculates miLevel using the current depth of Thread ID #1 (which is 
> 5) and the frame level of Thread ID #92 (which is 42), leading to a 
> negative number (-38).  Because the negative number is, well, 
> negative, later code refuses to issue the command that restarts the 
> debugged process.
> 
> It seems to me that in order to solve this, the initial part of Step 
> 3 needs to check to see if the current thread (and it really needs to 
> get the current thread in order to do this instead of relying on an 
> out-of-date cache) is the same as the one in which the Step Over, 
> Step Into, or Step Out operation was executed.  If so, then it needs 
> to restart that operation.  However, if the Shared Library event 
> takes place in a different thread, then that thread can just be 
> resumed with a Continue command.
> 
> Actually, what may need to happen is for the "lastRunningEvent" 
> information (see the source code to see what I'm referring to) to be 
> stored on a per-thread basis.  But I think the simpler solution 
> described in the previous paragraph may suffice in the short term.
> 
> Anyway, I'm hoping that someone can examine my analysis and let me 
> know if I'm spot on or off the mark.  If the former, I'll file a bug 
> report and fix my local copy.  If the latter, then I'd appreciate 
> hearing what the correct fix would be.
> 
> Thanks,
> 
> -- Keith Rollin
> -- Developer Tools engineer
> -- PalmSource, Inc.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!