Mail Archives: cygwin/1998/10/17/09:57:08
>
> In article <m0zSSij-0002fdC DOT cygnus DOT gnu-win32 AT jacob DOT remcomp DOT fr>,
> root <root AT jacob DOT remcomp DOT 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 AT cygnus DOT com" with one line of text: "help".
- Raw text -