This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [win32] Fix suspend count handling


On Sun, Nov 25, 2007 at 06:56:04PM +0000, Pedro Alves wrote:
> Christopher Faylor wrote:
>> On Sun, Nov 25, 2007 at 03:44:31PM +0100, Lerele wrote:
>>> What do you think?
>> There is some code in win32-nat.c which was a result of my uncertainty
>> about the Windows debugging API.  I thought that since we have a couple
>> more eyes on this now someone might know a bit more about how this
>> works.  Understanding the foundations is never a bad idea.
>> I'm not interested in gdbserver or what you think may be happening in
>> the future.  If the SuspendThread/ResumeThread code can be eliminated
>> from win32-nat.c along with all of the bookkeeping that is required to
>> avoid races then it may be a good idea to do so.  Whether it is a good
>> idea in light of future enhancements is a decision I can make but,
>> personally, I rarely see a good reason to keep code complication around
>> for the future unless someone is actually planning to do the work.
>> We can stop talking about this now since it is apparent that no one
>> actually knows the answer to my question.
>
> 100% Agreed.
>
> Just to let you know that I plan on looking at this.
> I'm specifically wanting to look at what we're doing
> when/if we need to step over something with all
> threads but the current stopped -- if that is supposed to
> happen, it looks like we're broken, we should be
> suspending all the threads but the current before
> resuming.

I was going to try just temporarily doing this to see what happens:

#define SuspendThread(hThread) 1
#define ResumeThread(hThread) 1

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]