Hmmm.... I fiddled a bit with winedbg and found it awful to use.... Maybe I'm too comfortable with visual debuggers :-) There's no plan to make a graphical front-end to it, for example extending DDD or better GVD ? I had a look at GVD sources and docs, and it shouldn't be too difficult to add a supported debugger... It has a quite good support for many external debuggers.... I see only une problem on it, as it seems to me that winedbg opens a new xterm and translates his i/o on it, which can confuse GVD as stated in docs. So, 2 questions : 1) - There's a way to instruct winedbg to not change xterm ? 2) - There's a volunteer with enough skills on winedbg that can help me to write GVD patch ? :-) Regards Max
Massimo a écrit :
Hmmm.... I fiddled a bit with winedbg and found it awful to use.... Maybe I'm too comfortable with visual debuggers :-) There's no plan to make a graphical front-end to it, for example extending DDD or better GVD ?
as I wrote some time ago, I have in my tree an implementation of the GDB remote protocol inside the wine debugger, which should let any well behaved gdb graphical front end debug a wine program (to some extent) A+
hmmmm... and is it possible to have a look at your tree ? :-) Alle 22:04, lunedì 8 luglio 2002, hai scritto:
Massimo a écrit :
Hmmm.... I fiddled a bit with winedbg and found it awful to use.... Maybe I'm too comfortable with visual debuggers :-) There's no plan to make a graphical front-end to it, for example extending DDD or better GVD ?
as I wrote some time ago, I have in my tree an implementation of the GDB remote protocol inside the wine debugger, which should let any well behaved gdb graphical front end debug a wine program (to some extent) A+
thanx !!! I'll try it just now... Btw, two more questions, if you can answer :-) 1 - When I try the commands --debugmsg inside winedbg, I get 'parse error' everytimes; the command appears in help, but doesn't work for me... is it a known issue, or I make some mistake ? 2 - Starting an app, while loading dll's and symbols, winedbg starts showing garbage like this : No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40b55000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) failure on type_info:T(3,1)=s8__name:/1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=*(0,23),32;type_info::(3,4)=#(3,1),(0,21),(3,5)=*(3,1),(0,1),(0,21);:qq _._9type_info;2A*2;(3,1);;operator=::(3,6)=##(3,7)=&(3,1);:__as__9type_infoRC9type_info;0A.;type_info::(3,8)=##(3,5);:RC9type_info; 0A.(3,9)=##(3,5);:PCc;1A.;before::(3,10)=##(0,12);:RC9type_info;2B.;name::(3,11)=##(3,2);:;2B.; operator==::(3,10):__eq__C9type_infoRC9type_info;2B.;operator!=::(3,10):__ne__C9type_infoRC9type_info;2B.;; ~%(3,1); at /1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=*( ..............<MORE>................. Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) ..............<MUCH MORE>................. Unknown type '&' failure on arg:p(0,25)=&(3,1) at (3,1) Nothing has been defined <> failure on bl:p(0,26)=*(2,17) at ..............<MUCH MUCH MORE>................. Is it a known bug or... ? 3 - Starting an app in winedbg (no symbol table for app...), debugger sometimes stops at app entry point (as I guess it should), sometimes before.... Is there a way to make it stop on app entry point, even with no symbols loades ? Or, even better.... there's a known (easy !) way to attach symbols generated by a disassembler (i.e. the best one, IDA) ? I've done it in windoze many times, with IDA+Soft-ICE, and it helps a lot ! ops, those where 3 questions :-) Thanx again for your answers ! Regards Max Alle 22:59, martedì 9 luglio 2002, Eric Pouech ha scritto:
Max a écrit :
hmmmm... and is it possible to have a look at your tree ? :-)
just send it to wine-patches (at least the part you requested interest for... ;-)
On Thu, 11 Jul 2002, Max wrote:
thanx !!! I'll try it just now... Btw, two more questions, if you can answer :-)
1 - When I try the commands --debugmsg inside winedbg, I get 'parse error' everytimes; the command appears in help, but doesn't work for me... is it a known issue, or I make some mistake ?
--debugmsg is not a command. It's a command line option. what you want to do is probably along the lines of 'set + relay' or something like that. Search for "debug messages" in documentation/debugger.sgml -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Yes, that's what I meant ! Having seen the 'debugmsg' command in winedbg help, I thought it was the command (damnt lazyness in reading docs...) Thanx Max Alle 01:23, mercoledì 10 luglio 2002, Francois Gouget ha scritto:
On Thu, 11 Jul 2002, Max wrote:
thanx !!! I'll try it just now... Btw, two more questions, if you can answer :-)
1 - When I try the commands --debugmsg inside winedbg, I get 'parse error' everytimes; the command appears in help, but doesn't work for me... is it a known issue, or I make some mistake ?
--debugmsg is not a command. It's a command line option. what you want to do is probably along the lines of 'set + relay' or something like that.
Search for "debug messages" in documentation/debugger.sgml
Max a écrit :
thanx !!! 3 - Starting an app in winedbg (no symbol table for app...), debugger sometimes stops at app entry point (as I guess it should), sometimes before.... Is there a way to make it stop on app entry point, even with no symbols loades ? Or, even better.... there's a known (easy !) way to attach symbols generated by a disassembler (i.e. the best one, IDA) ? I've done it in windoze many times, with IDA+Soft-ICE, and it helps a lot !
the "symbolfile foo" used to load the file foo and add symbol from it format of file foo is the regular unix format xxxxxxxx T name where xxxxxxxx address of symbol T type of symbol name string that describes the symbol I think it should still be working (untested though) dunno either if symbols generated by IDA and other tools will fit the format of the file note also that you may have to relocate the adress depending on the load address of the module the symbols are for (which, if needed, needs to be done at the file level) the attached patch should extent the symbolfile command like: symbolfile foo 0x12345678 to relocate symbols from foo at address 0x12345678 (assuming address in foo are relative to the start of the module) A+ Name: wdbg_sym ChangeLog: added offset for relocating symbols in symbolfile command License: X11 GenDate: 2002/07/10 11:54:38 UTC ModifiedFiles: debugger/debugger.h debugger/dbg.y debugger/hash.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/debugger.h,v retrieving revision 1.35 diff -u -u -r1.35 debugger.h --- debugger/debugger.h 13 Jun 2002 21:37:07 -0000 1.35 +++ debugger/debugger.h 10 Jul 2002 11:52:17 -0000 @@ -358,7 +358,7 @@ struct name_hash ** rtn, unsigned int ebp, struct list_id * source); -extern void DEBUG_ReadSymbolTable( const char * filename ); +extern void DEBUG_ReadSymbolTable( const char * filename, unsigned long offset ); extern void DEBUG_AddLineNumber( struct name_hash * func, int line_num, unsigned long offset ); extern struct wine_locals * Index: debugger/dbg.y =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/dbg.y,v retrieving revision 1.57 diff -u -u -r1.57 dbg.y --- debugger/dbg.y 2 Jun 2002 21:36:08 -0000 1.57 +++ debugger/dbg.y 10 Jul 2002 11:52:04 -0000 @@ -156,7 +156,8 @@ | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } | tCOND tNUM tEOL { DEBUG_AddBPCondition($2, NULL); } | tCOND tNUM expr tEOL { DEBUG_AddBPCondition($2, $3); } - | tSYMBOLFILE pathname tEOL { DEBUG_ReadSymbolTable($2); } + | tSYMBOLFILE pathname tEOL { DEBUG_ReadSymbolTable($2, 0); } + | tSYMBOLFILE pathname tNUM tEOL { DEBUG_ReadSymbolTable($2, $3); } | tWHATIS expr_addr tEOL { DEBUG_PrintType(&$2); DEBUG_FreeExprMem(); } | tATTACH tNUM tEOL { if (DEBUG_Attach($2, FALSE)) return 1; } | tDETACH tEOL { DEBUG_ExitMode = EXIT_DETACH; return 1; } Index: debugger/hash.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/hash.c,v retrieving revision 1.30 diff -u -u -r1.30 hash.c --- debugger/hash.c 31 May 2002 23:06:46 -0000 1.30 +++ debugger/hash.c 10 Jul 2002 11:53:12 -0000 @@ -797,7 +797,7 @@ * * Read a symbol file into the hash table. */ -void DEBUG_ReadSymbolTable( const char* filename ) +void DEBUG_ReadSymbolTable( const char* filename, unsigned long offset ) { FILE * symbolfile; DBG_VALUE value; @@ -839,7 +839,12 @@ if (!(*cpnt) || *cpnt == '\n') continue; if (sscanf(buffer, "%lx %c %s", &value.addr.off, &type, name) == 3) + { + if (value.addr.off + offset < value.addr.off) + DEBUG_Printf( DBG_CHN_WARN, "Address wrap around\n"); + value.addr.off += offset; DEBUG_AddSymbol( name, &value, NULL, SYM_WINE ); + } } fclose(symbolfile); }
Ok, I think that even if symbol files are not compatible, to write a converter would be a trivial task.... Maybe I'll take a look at it next days, if ida proves functional in wine. Before of that I wanna try your patch with DDD, yesterday I lost one our before understanding that something was missing :-) Of course the best would be integrate winedbg functionality in GDB, but I've noticed that it's not at all a trivial task....No time at all to look deep into both source codes :-( Thanx again for your help ! Max
Max a écrit :
thanx !!! 3 - Starting an app in winedbg (no symbol table for app...), debugger sometimes stops at app entry point (as I guess it should), sometimes before.... Is there a way to make it stop on app entry point, even with no symbols loades ? Or, even better.... there's a known (easy !) way to attach symbols generated by a disassembler (i.e. the best one, IDA) ? I've done it in windoze many times, with IDA+Soft-ICE, and it helps a lot !
the "symbolfile foo" used to load the file foo and add symbol from it format of file foo is the regular unix format xxxxxxxx T name where xxxxxxxx address of symbol T type of symbol name string that describes the symbol
I think it should still be working (untested though) dunno either if symbols generated by IDA and other tools will fit the format of the file note also that you may have to relocate the adress depending on the load address of the module the symbols are for (which, if needed, needs to be done at the file level)
the attached patch should extent the symbolfile command like:
symbolfile foo 0x12345678 to relocate symbols from foo at address 0x12345678 (assuming address in foo are relative to the start of the module)
A+
participants (4)
-
Eric Pouech -
Francois Gouget -
Massimo -
Max