From: fiveight <fiv...@to...> - 2008-04-16 03:01:48
|
Hi All: When I use "target remote tcp:127.0.0.1:8808" command in gdb 5.2.1, it fails. But when I use this command in 6.8 without any change of my codes, it works well.Is there any setting of gdb affect this? Thanks Fiveight |
From: Brandon S. <br...@oq...> - 2008-04-16 03:18:10
|
On Apr 15, 2008, at 8:01 PM, fiveight wrote: > Hi All: > When I use "target remote tcp:127.0.0.1:8808" command in gdb 5.2.1, > it fails. But when I use this command in 6.8 without any change of > my codes, it works well.Is there any setting of gdb affect this? > I'm not sure why off the top of my head, though most likely some bug or change was made. Is there a specific reason for preferring gdb 5.2.1 over 6.8, or 6.3 even? Brandon Sneed |
From: Lothar M. <mi...@lo...> - 2008-04-16 12:59:07
|
Hi Brandon, > Is there a specific reason for preferring gdb > 5.2.1 over 6.8, or 6.3 even? Actually, there is a reason: gdb 5.2.1 is the current stable release, while 6.3 is a release candidate, and 6.8 a technology preview. Best regards, Lothar |
From: Brandon S. <br...@oq...> - 2008-04-16 16:12:26
|
On Apr 16, 2008, at 5:58 AM, Lothar May wrote: >> Is there a specific reason for preferring gdb >> 5.2.1 over 6.8, or 6.3 even? > > Actually, there is a reason: gdb 5.2.1 is the current stable release, > while 6.3 is a release candidate, and 6.8 a technology preview. I can see with a compiler where you're shipping code to a customer this might be an issue, but with a debugger it seems more like self- inflicted pain. Brandon Sneed |
From: fiveight <fiv...@to...> - 2008-04-16 10:49:17
|
Absolutely no reason. I just want to know why, and next time I can solve this problem myself. Thanks Fiveight ----- Original Message ----- From: "Brandon Sneed" <br...@oq...> To: "MinGW Users List" <min...@li...> Sent: Wednesday, April 16, 2008 11:17 AM Subject: Re: [Mingw-users] The differences between gdb 5.2.1 and 6.8 > > On Apr 15, 2008, at 8:01 PM, fiveight wrote: >> Hi All: >> When I use "target remote tcp:127.0.0.1:8808" command in gdb 5.2.1, >> it fails. But when I use this command in 6.8 without any change of >> my codes, it works well.Is there any setting of gdb affect this? >> > > I'm not sure why off the top of my head, though most likely some bug > or change was made. Is there a specific reason for preferring gdb > 5.2.1 over 6.8, or 6.3 even? > > > Brandon Sneed > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Brandon S. <br...@oq...> - 2008-04-16 16:11:37
|
On Apr 16, 2008, at 3:49 AM, fiveight wrote: > Absolutely no reason. > I just want to know why, and next time I can solve this problem > myself. > Its most likely not a 'you' thing, but rather a GDB thing. I recommend using the latest unless something about it doesn't work for you, at which point, please let me know so I can possibly fix it. :D Brandon Sneed |
From: Lothar M. <mi...@lo...> - 2008-04-17 14:31:13
|
Hi, Brandon Sneed wrote: > I can see with a compiler where you're shipping code to a customer > this might be an issue, but with a debugger it seems more like self- > inflicted pain. I'm sorry but I disagree. You are saying that the stable release of gdb should not be used because it contains bugs which have been successfully fixed. What's the point in naming the new releases "release candidates" then, when they have been candidates over years? I'd say that, if the mingw "release process" continues as it is, in a few years there'll be nothing but technology previews, and users will have to find out for themselves which ones are the "most stable". Of course I'm aware of the fact that you are doing this in your free time, but I still think that this is something which could be improved. I might be wrong though, feel free to correct me. Best regards, Lothar |
From: Brandon S. <br...@oq...> - 2008-04-17 16:13:26
|
On Apr 17, 2008, at 7:30 AM, Lothar May wrote: > Hi, > > Brandon Sneed wrote: >> I can see with a compiler where you're shipping code to a customer >> this might be an issue, but with a debugger it seems more like self- >> inflicted pain. > > I'm sorry but I disagree. You are saying that the stable release of > gdb > should not be used because it contains bugs which have been > successfully > fixed. What's the point in naming the new releases "release > candidates" > then, when they have been candidates over years? Its ok to disagree, don't be sorry! The naming is more of an Earnie/ Keith call than mine, though I do think it is appropriate at this stage. My tech preview builds started in Jan, so years isn't really applicable, and the previous 6.x releases were pretty buggy. At any rate, a debugger, however unstable doesn't impact customers you're shipping code to like an unstable compiler might, so I still stand by my comment. However, if its an issue for you, I urge you to stick with the latest official release. > I'd say that, if the mingw "release process" continues as it is, in a > few years there'll be nothing but technology previews, and users will > have to find out for themselves which ones are the "most stable". Of > course I'm aware of the fact that you are doing this in your free > time, > but I still think that this is something which could be improved. I > might be wrong though, feel free to correct me. That may be the case, but you must understand that OSS projects don't follow the corporate definitions of much of anything. Release vs. Release Candidate, Tech Preview, etc doesn't matter nearly as much as what works for you. All 'Release' really means here is that its been tested extensively, and the only way MinGW can get tested extensively is by users. Given the current userbase (which seems to be growing considerably as of late) and this style of time-tested-QA validation, it will always take a long time for something to move into Release status. We could always draw a line in the sand and say "this is release quality" but that would be disingenuous to users and imply some extensive validation cycle had been performed. So while I would like this to improve as well, I don't see it happening in the near term. We're doing very well overall as a project I think, but by depending on users for validation and other OSS projects for much of our codebase/improvements, our hands are tied. Brandon Sneed |
From: Keith M. <kei...@us...> - 2008-04-17 19:56:17
|
On Thursday 17 April 2008 17:12, Brandon Sneed wrote: > On Apr 17, 2008, at 7:30 AM, Lothar May wrote: > > Brandon Sneed wrote: > >> I can see with a compiler where you're shipping code to a customer > >> this might be an issue, but with a debugger it seems more like > >> self- inflicted pain. > > > > I'm sorry but I disagree. You are saying that the stable release of > > gdb should not be used because it contains bugs which have been > > successfully fixed. What's the point in naming the new > > releases "release candidates" then, when they have been candidates > > over years? They are offered as such, so that you guys -- the users -- can test them, and report back to us that you are happy with them, and that *you* believe they are ready to be marked as full releases; until you start doing that, they will remain as "release candidates" until time immemorial. > Its ok to disagree, don't be sorry! The naming is more of an Earnie/ > Keith call than mine, though I do think it is appropriate at this > stage. My tech preview builds started in Jan, so years isn't really > applicable, and the previous 6.x releases were pretty buggy. At any > rate, a debugger, however unstable doesn't impact customers you're > shipping code to like an unstable compiler might, so I still stand by > my comment. However, if its an issue for you, I urge you to stick > with the latest official release. I debug most of my code on Linux, so don't use the Win32 builds of gdb much; thus I don't personally have enough good experience of how good, or how bad any of those releases may be. I rely on reports from you -- the users -- to guide me in my decision as to when to promote any package from "tech preview" to "release candidate" to "full release". > > I'd say that, if the mingw "release process" continues as it is, in > > a few years there'll be nothing but technology previews, and users > > will have to find out for themselves which ones are the "most > > stable". Of course I'm aware of the fact that you are doing this in > > your free time, but I still think that this is something which could > > be improved. I might be wrong though, feel free to correct me. Sure it can be improved; *you* can help to improve it, simply by testing, and providing the necessary feed back. Until *you* tell us that a release candidate is an improvement over the last stable release, then the status quo will simply prevail. > That may be the case, but you must understand that OSS projects don't > follow the corporate definitions of much of anything. Release vs. > Release Candidate, Tech Preview, etc doesn't matter nearly as much as > what works for you. All 'Release' really means here is that its been > tested extensively, and the only way MinGW can get tested extensively > is by users. Given the current userbase (which seems to be growing > considerably as of late) and this style of time-tested-QA validation, > it will always take a long time for something to move into Release > status. > > We could always draw a line in the sand and say "this is release > quality" but that would be disingenuous to users and imply some > extensive validation cycle had been performed. So while I would > like this to improve as well, I don't see it happening in the near > term. We're doing very well overall as a project I think, but by > depending on users for validation and other OSS projects for much of > our codebase/improvements, our hands are tied. Here, Brandon has pretty much said it all. Regards, Keith. |
From: Lothar M. <mi...@lo...> - 2008-04-18 11:43:54
|
Hi, I think that you are missing some points there. > Sure it can be improved; *you* can help to improve it, simply by > testing, and providing the necessary feed back. Until *you* tell us > that a release candidate is an improvement over the last stable > release, then the status quo will simply prevail. So you are waiting for - let's say 50 mails which confirm that it is rather stable. Or maybe 60 would be better? 70? I'd rather think that it is marked as release whenever you have the feeling it's fine because people keep reporting it is. To make the point clear: You could happen to wake up one morning, feel that the world is great and all is stable, so today is the day to mark things as release. (Sorry I don't mean to be personal, I just want to make that point clear.) And this is exactly like drawing a line in the sand, as Brandon called it, there's no difference at all, except on the time scale, because it happens kind of randomly and no one can rely on it. >> That may be the case, but you must understand that OSS projects don't >> follow the corporate definitions of much of anything. Release vs. >> Release Candidate, Tech Preview, etc doesn't matter nearly as much as >> what works for you. In my opinion, this is a plain wrong generalization. gcc is an open source project and the team does have a very strict release cycle and provides regular releases. I happen to work on an open source project, and we do loads of testing by ourselves, and we have automated tests, and release dates with beta phase, code freeze and all the usual things. We're also relying on "upstream releases", admittedly not as much as mingw does, but we still do. Or take the boost library as an example - they have a release process with loads and loads of testing by the team. Technology previews are great and I'm all in favour of them, because they allow people (including me) to use the latest stuff. But there should be some pointer to "This package is going to be the next stable release, please use this". Otherwise, because of upstream releases, there will be new technology previews, and even more technology previews, and none will ever be tested enough to become stable. See http://trolltech.com/developer/task-tracker/index_html?method=entry&id=175245 as example on why I insist on this issue. Requesting fixes so that any kind of commercial or semi-commercial library compiles/works using some latest mingw technology preview usually results in "we only support the stable releases". Best regards, Lothar |
From: Keith M. <kei...@us...> - 2008-04-19 21:32:40
|
On Friday 18 April 2008 12:43, Lothar May wrote: > I think that you are missing some points there. > > > Sure it can be improved; *you* can help to improve it, simply by > > testing, and providing the necessary feed back. Until *you* tell > us > that a release candidate is an improvement over the last stable > > release, then the status quo will simply prevail. > > So you are waiting for - let's say 50 mails which confirm that it is > rather stable. Or maybe 60 would be better? 70? > > I'd rather think that it is marked as release whenever you have the > feeling it's fine because people keep reporting it is. To make the > point clear: You could happen to wake up one morning, feel that the > world is great and all is stable, so today is the day to mark things > as release. (Sorry I don't mean to be personal, I just want to make > that point clear.) And this is exactly like drawing a line in the > sand, as Brandon called it, there's no difference at all, except on > the time scale, because it happens kind of randomly and no one can > rely on it. Fair comment. Ok, let's turn it around, like this: 1) Individual package maintainer's will retain the right to release tech. preview's as they consider appropriate, just as at present. 2) When these same package maintainers feel their package is ready for release, they may choose to post a release candidate; again, this remains as at present. 3) Three months (say) after publication of a release candidate, and in the absence of any show stopping defect report in respect of it, such a release candidate will be redesignated as a stable release. That still places the onus on you guys -- the users -- to test the tech. previews and release candidates, and to report your experiences, but now it will be your responsibility to *prevent* defective code from being designated as stable, rather than you encourage us to release. Does that seem preferable to you? Regards, Keith. |
From: Lothar M. <mi...@lo...> - 2008-04-22 19:30:14
|
Hi, Keith Marshall wrote: [...] > Fair comment. Ok, let's turn it around, like this: > > 1) Individual package maintainer's will retain the right to release > tech. preview's as they consider appropriate, just as at present. > > 2) When these same package maintainers feel their package is ready for > release, they may choose to post a release candidate; again, this > remains as at present. > > 3) Three months (say) after publication of a release candidate, and in > the absence of any show stopping defect report in respect of it, such a > release candidate will be redesignated as a stable release. > > That still places the onus on you guys -- the users -- to test the tech. > previews and release candidates, and to report your experiences, but > now it will be your responsibility to *prevent* defective code from > being designated as stable, rather than you encourage us to release. > > Does that seem preferable to you? Well, this is what was done with KDE 4 (at least I got the impression). There has been a lot of discussion about this, but I suppose they had to release so that the distributions would seriously start their integration work and they finally got loads of "testers" because of releasing, mainly users who would not bother to use the beta releases. For mingw, I personally would prefer that way, yes, as it would kind of force library providers to support the new versions (and report bugs they might encounter while they integrate the support). For example I cannot "judge" at all how stable gcc 4.2.1 is for my uses, because I simply cannot use it. Anyway, this is just my humble opinion, but maybe it could help if there was a bit of a higher priority on actually releasing. Best regards, Lothar |
From: fiveight <fiv...@to...> - 2008-04-30 02:40:15
|
Hi All: First of all, I have to admit that my English is poor. However, I will try my best to explain my problem. Pardon me. I am debugging a win32 program, I want to disassemble a stack frame.If the stack frame has debug info (means have source code), I can use the pc value directly with "disas" command of GDB. This command will dump the function surrounding the program counter of the selected frame. But if the stack frame does not have debug info, using pc value is not safe, because maybe there is no function limits surrounding the pc value(for example, in kernel32.dll). In this condition I can dump a rang address surrounding the pc value. For instance, the pc value is 0x40100, I can disassemble from 0x40000 to 0x40100, and disassemble from 0x40100 to 0x40200. The serious problem is that maybe 0x40000 is not a start of a instruction, because of the instructions of intel x86 can change their length, and in worst condition this will make the instructions from 0x40000 to 0x40100 are all wrong. If I disassemble from code section beginning to pc value, it may take me a long time. How can I get the correct context(disassembly) in this condition rapidly. Thanks. Fiveight |