Some questions about winedbg usability !
1) - Would it difficult to add an options (something like SHOWREGS=on/off) that allows to have regs displayed automatically after a breakpoint AND after a NEXTI command ? I find it painful to have to issue NEXTI and then INFO REGS each time.... remember old good ms-dos debugger !!! :-)
2)- What about the possibility to set off-code breakpoints ? It happens often that I must set a break (in asm code) that is in a DLL which isn't already loaded... That gives a BAD ADRESS, of course. Borland debugger accepts the breakpoints and set it when the code gets loaded. Now the only way is to set breaks in dll-loading routine, wait up to the wanted dll gets loaded and then put the break... awful !
3)- And now the difficultest ! After solving the point 2, what about a way to store/retrieve breakpoints settings from disk ? Finding a bug in asm code often requires days (hmmm... nights !) of stepping, and a way to save breakpoints settings would spare tons of notes on paper :-)
Regards
Max
On Mon, Jul 22, 2002 at 11:36:38PM +0200, Max wrote:
Some questions about winedbg usability !
- Would it difficult to add an options (something like SHOWREGS=on/off) that allows to have regs displayed automatically after a breakpoint AND after a NEXTI command ? I find it painful to have to issue NEXTI and then INFO REGS each time.... remember old good ms-dos debugger !!! :-)
From recent experiences with a different debugger, displaying the
changed register would probably be fine - and remind you what the intruction actually did (when you misread it).
David
Max a écrit :
Some questions about winedbg usability !
- Would it difficult to add an options (something like SHOWREGS=on/off) that allows to have regs displayed automatically after a breakpoint AND after a NEXTI command ? I find it painful to have to issue NEXTI and then INFO REGS each time.... remember old good ms-dos debugger !!! :-)
the best way would be to enhance the display functions with somethings like display $regs not difficult
2)- What about the possibility to set off-code breakpoints ? It happens often that I must set a break (in asm code) that is in a DLL which isn't already loaded... That gives a BAD ADRESS, of course. Borland debugger accepts the breakpoints and set it when the code gets loaded. Now the only way is to set breaks in dll-loading routine, wait up to the wanted dll gets loaded and then put the break... awful !
OTOH, it's also very awful to set a bp on memory which isn't mapped yet... you cannot write on it :-) anyway, we could do something like we do now for bp setting (expressed as a string) and automatically set the bp on DLL loading (if we can) rather easy (just follow what's done for deferred bp)
3)- And now the difficultest ! After solving the point 2, what about a way to store/retrieve breakpoints settings from disk ? Finding a bug in asm code often requires days (hmmm... nights !) of stepping, and a way to save breakpoints settings would spare tons of notes on paper :-)
that's a bit harder (especially, since we don't want the user to interact), but basically it's just setting the parser to read from a file stream instead of stdin
A+
.........
the best way would be to enhance the display functions with somethings like display $regs not difficult
Right, I'll try to do it on next days... Or do you plan do implement yourself ?
........
OTOH, it's also very awful to set a bp on memory which isn't mapped yet... you cannot write on it :-) anyway, we could do something like we do now for bp setting (expressed as a string) and automatically set the bp on DLL loading (if we can) rather easy (just follow what's done for deferred bp)
Yes, I meant deferred BP... is there already a way to set them now, at adress points ? Or it's only for source BPs ?
.......
that's a bit harder (especially, since we don't want the user to interact), but basically it's just setting the parser to read from a file stream instead of stdin
I don't understand the thing of avoiding user interaction.... I was thinking about a command like 'store breaks <filename>' and 'load breaks <filename>... or maybe, better, a way to store all winedbg settings on file.
Regards
Max
OTOH, it's also very awful to set a bp on memory which isn't mapped yet... you cannot write on it :-) anyway, we could do something like we do now for bp setting (expressed as a string) and automatically set the bp on DLL loading (if we can) rather easy (just follow what's done for deferred bp)
Yes, I meant deferred BP... is there already a way to set them now, at adress points ? Or it's only for source BPs ?
this works now for function names (but not source bp like file.c at line 123, nor for addresses) I'm currently finishing a patch that implements what you want
that's a bit harder (especially, since we don't want the user to interact), but basically it's just setting the parser to read from a file stream instead of stdin
I don't understand the thing of avoiding user interaction.... I was thinking about a command like 'store breaks <filename>' and 'load breaks <filename>... or maybe, better, a way to store all winedbg settings on file.
I've almost finished the 'source foo' winedbg commands, which will read all (winedbg) commands stored in file foo. what you propose if way too specific to your current problem. but the 'source' command, there shouldn't be any user interaction (like asking the user for some more information)
A+
Alle 18:24, lunedì 29 luglio 2002, Eric Pouech ha scritto: ............
this works now for function names (but not source bp like file.c at line 123, nor for addresses) I'm currently finishing a patch that implements what you want
great, I think even it can be dangerous, it can spare much debugging time too!
...............
I've almost finished the 'source foo' winedbg commands, which will read all (winedbg) commands stored in file foo. what you propose if way too specific to your current problem. but the 'source' command, there shouldn't be any user interaction (like asking the user for some more information)
yes, I meant something like that.... Quite like a command macro recorder, or a simpler a scripting ability. It happens often to loose much time to reach the correct debugging point, and then loose the command sequence to reach it... I guess with your patch that'll be much better
Btw, I tried GDB with wine, but it's really awful that it doesn't understand threading/process modell of wine, so I went back to winedbg. Tried your remote add-on too, but no success... maybe I did something wrong. I'm thinking more and more to write a graphical front-end for winedbg, maybe using as a starting point KDBG... Simple and clean interface, not too many complicated (and also quite unuseful :) ) commands.... I 'now that it'll never (?) go in cvs, but it can be useful as an external add-on too.... A little (and maybe dummy, as usual!) question : as winedbg is a winelib app, is it possible to link it with QT, or there are some known problems ?
Regards (and thanx for the patches !)
Max
Tried your remote add-on too, but no success... maybe I did something wrong.
what's wrong ? could you explain a bit more ?
A little (and maybe dummy, as usual!) question : as winedbg is a winelib app, is it possible to link it with QT, or there are some known problems ?
well, as usual, the threading model may be an issue. to my knowledge noone ever tried it
A+
-
David Laight -
Eric Pouech -
Massimo -
Max