From: Chris S. <ir0...@gm...> - 2008-03-31 12:40:18
|
Hey All, Following the GDB mailing list, I see that 6.8 is now the official release and it supports MinGW natively. I know that in the past both Dave Murphy and Brandon Sneed have released versions of gdb. Are either of you guys up for rolling out a new release? Also, in general, now that it looks like we are standardizing on packaging, should we maintain some sort of 'maintainers' list (something similar to what the Cygwin folks do) so that we don't have people duplicating effort? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Brandon S. <br...@oq...> - 2008-03-31 14:13:55
|
On Mar 31, 2008, at 5:40 AM, Chris Sutcliffe wrote: > Hey All, > > Following the GDB mailing list, I see that 6.8 is now the official > release and it supports MinGW natively. I know that in the past both > Dave Murphy and Brandon Sneed have released versions of gdb. Are > either of you guys up for rolling out a new release? > 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! Brandon Sneed |
From: Christopher F. <me...@cg...> - 2008-04-02 01:56:25
|
On Mon, Mar 31, 2008 at 07:12:45AM -0700, Brandon Sneed wrote: >On Mar 31, 2008, at 5:40 AM, Chris Sutcliffe wrote: >> Hey All, >> >> Following the GDB mailing list, I see that 6.8 is now the official >> release and it supports MinGW natively. I know that in the past both >> Dave Murphy and Brandon Sneed have released versions of gdb. Are >> either of you guys up for rolling out a new release? > >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 noticed 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 there is already a patch out there. cgf |
From: Brandon S. <br...@oq...> - 2008-04-02 02:32:08
|
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 > noticed > 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 > there > 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: http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=internap&filename=gdb-6.8-mingw.patch&12049712 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. Brandon Sneed |
From: Christopher F. <me...@cg...> - 2008-04-02 17:33:04
|
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 >> noticed >> 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 >> there >> 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: > >http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=internap&filename=gdb-6.8-mingw.patch&12049712 > >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. Thanks for the pointer. cgf |
From: Christopher F. <me...@cg...> - 2008-04-07 03:43:00
|
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 >>> noticed >>> 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 >>> there >>> 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: >> >>http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=internap&filename=gdb-6.8-mingw.patch&12049712 >> >>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 soon. FYI, cgf |
From: Brandon S. <br...@oq...> - 2008-04-07 17:30:51
|
On Apr 6, 2008, at 8:42 PM, Christopher Faylor wrote: >> 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 > soon. > Thanks for looking into this Chris. I found Pedro's patch, and it appears to be much more thorough than mine. Do you know what the reasons are for Pedro's patch to not be included? I can't tell from the discussion there. Or is it perhaps that your changes make the original patch non-applicable? Thanks! Brandon Sneed |
From: Christopher F. <me...@cg...> - 2008-04-07 19:16:50
|
On Mon, Apr 07, 2008 at 10:30:11AM -0700, Brandon Sneed wrote: >On Apr 6, 2008, at 8:42 PM, Christopher Faylor wrote: >>> 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 >> soon. >> > >Thanks for looking into this Chris. I found Pedro's patch, and it >appears to be much more thorough than mine. Do you know what the >reasons are for Pedro's patch to not be included? I don't really know but I assume that the second round of his patch is just a round tuit problem, i.e., someone with global privileges has to inspect it and pass judgement on it. >I can't tell from the discussion there. Or is it perhaps that your >changes make the original patch non-applicable? No, AFAICT, my changes are unrelated. I had to make them because some fairly major breakpoint-related changes were added to inflow.c in the last few months and they (apparently) broke some assumptions that I was making in win32-nat.c. I think Pedro's changes are still required, though. For my particular workflow which consists of (gdb) dll cygwin1.dll (gdb) bp <somewhere in cygwin1.dll> (gdb) r *hit the breakpoint* I only need my changes. Setting a breakpoint where there aren't any symbols loaded yet is a slightly different scenario. cgf |
From: Brandon S. <br...@oq...> - 2008-04-09 20:21:16
|
On Apr 7, 2008, at 12:16 PM, Christopher Faylor wrote: > On Mon, Apr 07, 2008 at 10:30:11AM -0700, Brandon Sneed wrote: >> >> Thanks for looking into this Chris. I found Pedro's patch, and it >> appears to be much more thorough than mine. Do you know what the >> reasons are for Pedro's patch to not be included? > > I don't really know but I assume that the second round of his patch is > just a round tuit problem, i.e., someone with global privileges has to > inspect it and pass judgement on it. The patch looked pretty old. I figure i probably shouldn't hold my breath waiting for its inclusion. :D > > >> I can't tell from the discussion there. Or is it perhaps that your >> changes make the original patch non-applicable? > > No, AFAICT, my changes are unrelated. I had to make them because some > fairly major breakpoint-related changes were added to inflow.c in the > last few months and they (apparently) broke some assumptions that I > was > making in win32-nat.c. I think Pedro's changes are still required, > though. For my particular workflow which consists of > > (gdb) dll cygwin1.dll > (gdb) bp <somewhere in cygwin1.dll> > (gdb) r > *hit the breakpoint* > > I only need my changes. Setting a breakpoint where there aren't any > symbols loaded yet is a slightly different scenario. > On a semi-related note (you're making GDB changes).. In gdbserver, remote-utils.c, around line 620. There is this hack for NetBSD that causes ctrl-c to not be handled properly after the first try. ie: one can't break anymore via ctrl-c. The specific problem is with the c != '\003'. I only mention it because it breaks a significant piece of functionality and is quite suspect regarding the description above... /* Protect against spurious interrupts. This has been observed to be a problem under NetBSD 1.4 and 1.5. */ I would think the best thing to happen is for NetBSD to fix their problem and for fixes like this to be rejected. I'm probably preaching to the choir, but it might be helpful for you to know. I did a build here and verified that removing the c != '\003' does resolve the issue, but i'm not sure what the implications are elsewhere. I'll post a build and patch shortly. Brandon Sneed |