This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb


> 
> In article <m0zSSij-0002fdC.cygnus.gnu-win32@jacob.remcomp.fr>,
> root <root@jacob.remcomp.fr> wrote:
> >gdb gdb...
> >1) When I issue the disassemble command, it will disassemble a bit and then
> >   tells me:
> >---Type <return> to continue, or q <return> to quit---
> >
> >Beware of typing q <return>... 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 <nexti> 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@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]