From: root AT jacob DOT remcomp DOT fr (root) Subject: gdb and system dlls 26 Oct 1997 08:43:53 -0800 Message-ID: Content-Type: text To: gnu-win32 AT cygnus DOT com 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".