On Wed, Apr 02, 2008 at 01:32:55PM -0400, Christopher Faylor wrote:
>On Tue, Apr 01, 2008 at 07:31:23PM -0700, Brandon Sneed wrote:
>>On Apr 1, 2008, at 6:55 PM, Christopher Faylor wrote:
>>> On Mon, Mar 31, 2008 at 07:12:45AM -0700, Brandon Sneed wrote:
>>>> I'll check it out and see if the pending breakpoints and prefix fixes
>>>> are in there yet. If so, i'll upload a new version, otherwise, i'll
>>>> need a little bit to create a patch. I was supposed to do this for a
>>>> 6.7 cvs build and completely forgot. doh!
>>> There seems to be a problem with pending breakpoints, actually. I
>>> this as I was getting ready to make a cygwin release.
>>> Did I miss a patch for this or isn't it a windows-specific thing?
>>> If it is
>>> a windows-specific thing I'll see that it gets added.
>>> Regardless, it will save me some time tracking down the problem if
>>> is already a patch out there.
>>I don't think its a Windows specific problem, though i haven't tried
>>it on any other platforms. The issue is basically that if one tries
>>to set a pending breakpoint before symbols have loaded, the breakpoint
>>is refused rather than being created as pending. I put a very minimal
>>patch up here:
>>It pretty much just comments out the two lines that check for partial
>>symbols and full symbols and the error message if both are false. If
>>its not a windows specific thing, it may be that its more noticable in
>>windows as one is less likely to have source for something (going out
>>on a limb here). For instance if one is making a DLL plugin for
>>another vendor's application, without this fix, i have to wait for the
>>plugin to be loaded, then break the app, then set the breakpoint which
>>is pretty harsh and limits the scope of what i can run through GDB.
>I have the same symptom in the cygwin version of gdb but it manifests as
>an "I/O error" rather than what your patch seems to be addressing.
>I'll give your patch a try, though. At least it's a start.
I've applied the patch which Pedro Alves posted to the gdb mailing list
and that did not solve my I/O error problem. I tracked the problem
down to a new requirement for setting a global "stop_soon = STOP_QUIETLY;"
in the win32-nat.c function "do_initial_win32_stuff". That change is in
the recently-released cygwin gdb and I'll be checking it into the trunk