[RFA] get win32-nat target to compile again.

[RFA] get win32-nat target to compile again.

[Pierre Muller]

Win32-nat target is broken since december 27.,
when Mark moved some macros  from tm-i386.h 
to i386-tdep.h which isn't included in the win32-nat.c.

The patch below does fix the compile failure, but 
I am unsure if this is the correct approach
(maybe it should rather be included inside another include file ?)

By the way, are there any plans to support win32 for other 
processors as i386 ?
A big part of the win32-nat.c code is processor independant, but 
several recent additions (include my not yet accepted debug register 
support) do have proc specific code...


2002-01-06 Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c: Add i386-tdep.h dependency.

Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.41
diff -u -r1.41 win32-nat.c
--- win32-nat.c 2001/12/03 08:19:01     1.41
+++ win32-nat.c 2002/01/07 10:07:59
@@ -34,6 +34,7 @@
  #include "completer.h"
  #include "regcache.h"
  #include "top.h"
+#include "i386-tdep.h"
  #include <signal.h>
  #include <sys/types.h>
  #include <fcntl.h>



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFA] get win32-nat target to compile again.

[Christopher Faylor]

On Mon, Jan 07, 2002 at 11:17:45AM +0100, Pierre Muller wrote:
>Win32-nat target is broken since december 27.,
>when Mark moved some macros  from tm-i386.h 
>to i386-tdep.h which isn't included in the win32-nat.c.

I tried to apply this patch but it is malformed.

However, it looks right, so if you want to check it in, please do.

I think you still want to investigate why the patch is screwed up,
though.

>The patch below does fix the compile failure, but I am unsure if this
>is the correct approach (maybe it should rather be included inside
>another include file ?)
>
>By the way, are there any plans to support win32 for other processors
>as i386 ?  A big part of the win32-nat.c code is processor independant,
>but several recent additions (include my not yet accepted debug
>register support) do have proc specific code...

The win32-nat.c code sort of assumes cygwin right now.  I plan on adding
some more code from Tak Ota at some point which allows command line
redirection under cygwin.

That's about it for any plans *I* have for win32-nat.c.

cgf

>2002-01-06 Pierre Muller  <muller@ics.u-strasbg.fr>
>
>	* win32-nat.c: Add i386-tdep.h dependency.
>
>Index: win32-nat.c
>===================================================================
>RCS file: /cvs/src/src/gdb/win32-nat.c,v
>retrieving revision 1.41
>diff -u -r1.41 win32-nat.c
>--- win32-nat.c 2001/12/03 08:19:01     1.41
>+++ win32-nat.c 2002/01/07 10:07:59
>@@ -34,6 +34,7 @@
>  #include "completer.h"
>  #include "regcache.h"
>  #include "top.h"
>+#include "i386-tdep.h"
>  #include <signal.h>
>  #include <sys/types.h>
>  #include <fcntl.h>

Re: [RFA] get win32-nat target to compile again.

[Pierre Muller]

At 19:43 07/01/2002 , Christopher Faylor a écrit:
>On Mon, Jan 07, 2002 at 11:17:45AM +0100, Pierre Muller wrote:
> >Win32-nat target is broken since december 27.,
> >when Mark moved some macros  from tm-i386.h 
> >to i386-tdep.h which isn't included in the win32-nat.c.
>
>I tried to apply this patch but it is malformed.

Sorry, I forgot again about these Eudora transformations...

>However, it looks right, so if you want to check it in, please do.

Done.




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFA] get win32-nat target to compile again.

[Michael Snyder]

Pierre Muller wrote:
> 
> Win32-nat target is broken since december 27.,
> when Mark moved some macros  from tm-i386.h
> to i386-tdep.h which isn't included in the win32-nat.c.
> 
> The patch below does fix the compile failure, but
> I am unsure if this is the correct approach
> (maybe it should rather be included inside another include file ?)

We have used the same fix for several other i386 targets already.