From: root AT jacob DOT remcomp DOT fr (root) Subject: Re: gdb 17 Oct 1998 09:57:08 -0700 Message-ID: References: <700b1f$drq$1 AT cronkite DOT cygnus DOT com> Content-Type: text To: cgf AT cygnus DOT com (Christopher G. Faylor) Cc: gnu-win32 AT cygnus DOT com > > In article , > root wrote: > >gdb gdb... > >1) When I issue the disassemble command, it will disassemble a bit and then > > tells me: > >---Type to continue, or q to quit--- > > > >Beware of typing q ... It will crash immediately. Has anyone else > >experienced this bug? > >I am debugging a windows program. > > I Haven't experienced this. Yes. I am using mingw32 without any bash or shell, directly from cmd.exe This is probably the reason. There is NO cygwin no nothing. Just the binaries for mingw32 as distributed by Mumit. > > >3) > > gdb is unable to follow the stack when there is a trap in a system call. > > I have developed recently an algorithm for doing this. It wouldn't be a > > bad idea if gdb would improve this situation. It is not at all that > > difficult. > > Enlightenment would be gratefully accepted. Do the following: 1. When the program starts, save its original esp. 2. When the program crashes, get its context into (say) Context. 3. Substract original esp - Context.Esp. If this is bigger than 1MB, the user program crashed with stack overflow. Beware of this situation! In general I use only the first 4096 bytes in the stack. If the difference is bigger than that, I ignore the rest. 4. With this stack size, allocate space for this stack. (use malloc, whetever) 5. Read the stack from the freezed user's process into this array you have just allocated. 6. Now begins the most difficult part: finding the saved user routine in the stack. I use following algorithm. 6.1: Read 4 bytes from the stack into integer s. 6.2: Does this integer correspond to a section of user code space? I.e. go to your list of the user's code spaces (modules+libraries). Is this number greater than the start of this code section and less than its end? 6.3: If yes, this could be just a coincidence. Verify that at this place in the user's code space there is a function call, i.e. a call instruction. To verify this, you should know that a call instruction can have a variable length, but normally they are program counter relative calls, using up 6 bytes. The saved return value in the stack corresponds to the end of the call instruction. Substract 4 from this value (s), and you should see the call opcodes there. If you see them, this place is indeed a function call, and it would be very unlikely that this value in the stack is NOT a return address. Exit this loop with SUCCESS and return this address in user's space as the last line the program was executing before going into the system dll. If you do not find the opcodes in this section of user code, this means that that value in the stack wasn't a return address. 6.4: Increment your pointer by 4 and go to step 6.1 if there are still stack locations to investigate. If not, you have arrived at the end of the stack. Return FAILURE. This algorithm works 90% of the time. > > >4) The command line interface is... well forget it. > > I use the command line interface routinely without problem. If you have > a specific complaint let's hear it. > Well, I am specifically against command lines that force you to memorize commands like hell!!! It would be possible to use the console attributes to support a menu where you would just have to select the command isn't it? Running under a windows system, you could even create a popup menu or something. But obviously you know the commands by heart already, so you do not notice how frustrating it can be to type: help running help this help that at each step!!! > >5) It is difficult to follow the program execution at the assembly level. > > The command works, but instead of showing me the assembly > > instruction that will be executed, it insists in showing me the source > > line... So I am blind as to what the hell the machine is doing. > > display /i $pc OK. Thanks, but tell me, if I do the nexti command (i.e. the next assembly instruction) couldn't the software figure out that this should be done automatically??? Why do I have to type it in??? > > >6) You can't set a breakpoint when the program is running. In general, gdb > > is freezed when the program is running. Now, doing this is not specially > > difficult: you just stop the running thread, set the > > breakpoint, and then you resume... not rocket science really. > > Not sure what you want here. Do you want to be able to stop the running > program with CTRL-C maybe? Obviously. I would like to stop it, examine where it is, maybe set the program counter to another place, etc. I.e. i would like to use the debugger to control program execution... > > >7) There is no way to stop the program. The 'kill' command is kind of > > useless, since you can't type anything into gdb unless the program is > > stopped!!! Gdb reminds me of those days when I used the "debug" command > > line debugger from MS-DOS. > > Patches to correct this behavior would be gratefully accepted. The basic problem with gdb is that it: 1) Is single threaded, i.e. even under my linux system it will not fork() to execute the program. When the program is running I can't do anything in the debugger!!! Modern debuggers are multi-tasking. You can use the debugger while the program is running. This would require some basic redesign of the software. 2) Its command line interface has to be thrown away, and a more modern user interface has to be built. 3) It doesn't understand much from the windows system. (gdb) break CreateWindow Function "CreateWindow" not defined. This knowledge would have to be written into gdb. To correct this misgivings would mean writing gdb again. This would take me at least 6 months full time. Just to get to the point where I can build gdb from source is a week effort!!! (See the messages posted here by people that have tried that). I considered using a combination of gdb/graphical display as the 'ddd' program does. I dropped that because gdb is just too primitive to be used as a serious debugger. It would require more effort than writing a new debugger costed me anyway. The debugger is the CENTRAL piece of a compiler system. If its unusable/or bad software built with the compiler will be always buggy. Now let's be honest: Has any one here built a moderately complex piece of software without a debugger??? -- 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".