> The assert at the beginning of the DEBUG_CopyFieldlist function fails.
> The types are DT_STRUCT and DT_POINTER. I thought that DT_POINTER could
> point to a DT_STRUCT, but it is not. It is pointing to a DT_BASIC type. So I
> commented the call to DEBUG_ParseTypeTable in DEBUG_ProcessPDBFile. This way
> I was able to debug simple apps, but not the corel suite.
DT_POINTER can point to anything... how would you store an int* type ? (int
is stored as a DT_BASIC type)
however, I don't know what fails here :-(
> len = (sym->generic.len + 3) & ~3;
> len += ptr.c[16] + 1;
> increment = (len + 3) & ~3;
could it be that ptr.c[16] has to be considered as an unsigned char (and
not a signed char) ? (
> I tried to debug one of my test applications with a build from winehq, but
> something seems broken there. In both trees, each process has a list of his
> modules. DEBUG_InitCurrProcess is loading the symbol list when we first
> enter the debugger. The problem is that the current process is not the one
> containing "myApp.exe" in his list, so "myApp.pdb" is never parsed. In our
> tree, the process calling DEBUG_InitCurrProcess is the good one, but we did
> not merged all the work that has been done on the new debugger, so it may be
> related...
this should be fixed in current cvs tree as a different debugging thread is
created for each debugged process. however, since for now, all debugging
threads share the same consoles, actually debugging several processes rather
undoable
HTH
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle