Tyler Littlefield wrote:
> Hello,
> I've got a quick couple of questions.
> I'm debugging a program, and don't have sym tables loaded.
> I'd like to figure out how to get the most information possible.

Assuming VC++, compile with program database (PDB) support.  The VC++ 
debugger is the best debugger in existence.


> I'd like to obtain function lists, if possible, and memory values, which I 
> think is all I can really get.
> My question is this, I know I can set breakpoints, and do a backtrace that 
> way, but how would memory values be readable?

You can configure the VC++ IDE to recognize any structure/class/whatever 
you create if the debugger doesn't already recognize it in its entirety 
(e.g. an array only shows the first value but you know there are more 
values, you can configure the debugger to recognize the rest of the array).


> I can start at the beginning of the program's memory and traverse through the 
> memory, but it ends up showing up as a bunch of chars, is there a way I can 
> translate this?

I have no idea why you are doing this.  There is almost no need to ever 
drill into the memory view (let alone the assembler view).


> Any tips would be welcome--I think I need more debugging knowledge than I 
> currently have.
> I'm interested in working with windbg and dbg for linux, so  I can learn the 
> techniques of both.

Linux has gdb.  And KDevelop is probably the best IDE wrapper for gdb.


> also, an off question,
> When a dll is mapped into memory for a program on windows,
> Is the dll's memory shared, or does each program map it's own individual dll?

Depends.  If the DLL has a segment declared as shared memory, then that 
section is mapped into shared memory.  The rest of the DLL, though, is 
loaded into the virtual process space.


> I think that's about it.
> I'm basically trying to dig into the internals of how things work, how memory 
> is managed, etc and trying to learn how to debug things along the way.

Learning how to use a debugger while learning the internals of an OS is 
not a good idea.  To learn how memory is managed, you can look at the 
implementation for your compiler (assuming source is available).  'new' 
and 'delete' aren't magical.


> Also, I've learned how to use kernel modules in linux, if a need ever arises.
> I'd love to be able to learn how the ddk works and driver development for 
> windows, if anyone can point me toward a book or resource there too.

Device driver development is a difficult art form for any OS.

-- 
Thomas Hruska
CubicleSoft President
Ph: 517-803-4197

*NEW* MyTaskFocus 1.1
Get on task.  Stay on task.

http://www.CubicleSoft.com/MyTaskFocus/

Reply via email to