Re: [mingw32] Re: Compiling gdb for mingw32

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Mumit Khan wrote:
> 
> On Sun, 9 Jan 2000, Kai Ruottu wrote:
> 
> Note that my patches for mingw port of gdb are very "simple minded", and
> probably chock full of bugs. Kai, have you sent your changes into the
> gdb folks? If not, you can send it to me and I'll forward it on (provided
> you're willing to assign the changes of course, you know the drill).

 Those changes are just those 'how-to' things, like "Take the Cygnus-made
'ser-win32s.c' from the Cygnus GDB sources and copy it to the (Cygnus-maintained?)
GDB sources, and fix some things by running these patches".

 Perhaps Cygnus should first donate their 'gdb/mswin' subdir or parts from
it to the 'official' GDB sources (now gdb-4.18), so that the stuff could be
fixed there. The same things would be needed for getting the gdbtk-stuff
glued into gdb-4.18 -- just copying it from the Insight sources and running
then some patches to the stuff.

 For me it would be easiest to put my 'gdb-4.18.2' sources somewhere, already
fixed for mingw32 and mingw32s (Win3.2/Win32s without a 'console'), than provide
huge patches with all the tcl/tk/tix/itcl/libgui stuff inside them.

 The tcl/tk-stuff was copied from some early (Aug-Sept) Insight-sources, I
haven't tried to copy the changes from the later stuff (should be easy), or
tried seriously to get the current snapshots ported to mingw (the new event-
handling system in the 'gdb'-subdir seemed to need quite a lot changes even
in the first Insights where I tried the mingw host), so the 'almost' working
(for mingw) gdb-4.18 sources seemed to be much easier.  The Insight seems to
change more and more Unix-dependent :-( so that only Cygwin can handle the
code under Win32.
 
> Two problem with gdb on Mingw that I never bothered fixing are:
> 
> - `dir' command can't handle dos/windows paths. We need to teach Gdb
>   to handle dos/windows pathnames and use ';' separated paths.

 This seems to be a problem with very big sources divided into separate
directories, or wanting to debug the C-libs, DLLs etc. system-stuff, which
should be already debugged. Ok, I needed the dir-command when trying to
solve why all the mingw-hosted Insights crash under NT3.51. But I used a
Cygwin-hosted Insight to debug the Mingw-hosted GDB.

> - command line redirection doesn't work. This is a bit trickier -- we
>   need to parse the command line and see if there's redirection, and
>   if so, munge the input/output/error handles before calling
>   CreateProcess on the debuggee.

 Where is this redirection needed?

 The problems I have met with Insight-GDBs (and always wondered why they
are there and why nobody else hasn't seen them as 'bugs'), are those
related to the 'stdout' and 'stderr' for the program to debug. The native
GDBs work probably ok with them, but those 'remote-GDBs' or 'cross-GDBs'
all don't.

 What I think they should do, is that when the program to debug wants to
output something to 'stdout', this should appear in the 'Terminal Window'
(i.e. the 'black console' created in Win32 or to the console/xterm from
where the Insight was started). But the 'stderr' should be the 'Console
Window' -- the window for GDB-commands. For systems without a 'system
console', like Win3.1/Win32s, the 'stdout' should be the same as the
'stderr', i.e. the 'Console Window'.  Yet I haven't found any sense in
those 'write_callback' or something in the GDB sources...  Quite many
Insights, if built from the 'out-of-the-box' Cygnus sources, don't put
the 'printf()' output anywhere to be seen. The program runs in the built-
in simulator (or in the target board) but no stdout-output from it can be
seen anywhere...

 So I have fixed those 'write_callback's going nowhere to pure 'write's
in some simulators, or fixed the unworking 'write_to_stdout()' (or something)
to a pure 'write(stdout,...)' in 'sim/common', so that all my Insight's should
work just in the same (and expected) way (with the simulators)...

 I'm sure I have talked about this "printf()'s are now going nowhere" problem,
but got no sane answers...  The only one I got, I got from the earlier
'gdbtk-GUI', where the H8/300 version outputted to the GDB-command window,
and only after the whole program had been run (!). The answer was that "it
should work this way"...  However I didn't believe and fixed the 'stdout'
output to go to the Win32-console/xterm and appear there immediately after the
'printf()' had been run in the debugged program, so stepping through a program
with output to 'stdout' would seem to happen in 'real-time', not gathered into
some mystical buffer and seen only when the program has been gone to exit().

 Perhaps you meaned these same things with the 'command line redirection
doesn't work'. Perhaps one should give some GDB-redirection command before
seeing the 'stdout' in the Win32-console/xterm?  And my thought about this
needing to happen always as the default is wrong.  Ok, I must browse those
Insight-docs again to see what it says about where and when the program
output should be seen...

Cheers, Kai