Subject: gdb and system dlls
From: [email-masked] (root)

26 Oct 1997 08:43:53 -0800
Message-ID: <[email-masked]>
Content-Type: text
To: [email-masked]

It would be more meaningful for the user if gdb showed the name of the
system function that produces a trap instead of just showing a meaningless
address.

I am adding to lcc-win32's debugger this capability, and I thought this could
be of interest to some of you. If you are not interested in this kind of
rather technical stuff, just skip this message.

Procedure for getting the symbolic name of an address in the system dlls.
-----------------------------------------------------------------------
Phase 1: Find the name of the file containing the debug info.
1. Open the dll file.This supposes that gdb is intelligent enough to keep the 
   name of all loaded dlls, with their starting address etc. Win32 informs the
   debugger when the applications does an implicit or an explicit LoadLibrary.
   The information Win32 passes to the debugger is quite complete. 
2. Do a MapViewOfFile so the parsing of the dll file is easier.
   Look at the NTheader structure, specifically in the Optional Header. 
   There is, in that header, a DATA_DIRECTORY structure. There you will find
   at position 6 (IMAGE_DIRECTORY_ENTRY_DEBUG) the offset of the debug directory
   in the dll.
3. Follow that pointer, that gives an offset within the .rdata section. Find
   the .rdata section, add that offset, and substract its virtual address of
   course since it is a relative address.
4. Once the debug directory found, find an entry with type == MISC. Most of the
   time is the only entry. This debug dir entry holds the offset in the file of
   the name of the file containing the debug information. 
   Move to that offset, and read that information 12 bytes pass the start.
   (This offset of 12 comes for a signature of 1L, and other 2 longs containing
   the size of the MISC debug info and other stuff)

Phase two: Read the debug information.
Debug information for the system dlls is distributed in the form of .dbg files.
The structure of those files is:
Header (described in winnt.h: IMAGE_SEPARATE_DEBUG_HEADER)
Section Table
Exported names
Symbol Table
Debug Directory
The .dbg debug directory contains pointers to the symbol table. Follow that.
With the symbol table, loop for all symbols finding the one that has the
closest address that the one you are looking for. Remember that you should
ignore all symbols with type == 0, they are just debug symbols like .file.
Anyway, since we are not at Microsoft's headquarters, we do not care
about the name of the source files...

Once you find that symbol you are done...

PHASE three: finding out how long the function that crashed is.
Additional information about the size of the system functions, size of
prologue and local variables can be found in the FPO debug info. (Frame Pointer
Omission). This would allow gdb to avoid the 'probably corrupted stack' message.

I am modifying my debugger to use this info. It is not easy, but debuggers
aren't easy stuff either.

I hope you find this information useful.

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".