Re: Support of gdb for Windows 64 native systems

> Date: Fri, 12 Oct 2007 09:11:32 -0700
> From: Joel Brobecker <brobeckeradacore.com>
> Cc: Daniel Jacobowitz <drowfalse.org>,
Kai.Tietzonevision.com,
> 	gdbsourceware.org
> 
> > Actually, wouldn't it be better to separate the
two completely?  That
> > should avoid a lot of ugly ifdefs, and make each
native backend much
> > cleaner, I think.
> 
> The issue with that is that we'll end up duplicating a
bit of code.

So what? the duplicates will never be linked into the same
build.  We
already have duplicate code in targets that are alike, one
more cannot
hurt.

In my experience, mixing two different targets is asking for
trouble
in the long run.

> In our merge, I counted 5 instances of
"ifdef/ifndef __MINGW32__

You need to count "ifdef __CYGWIN__" as well.

> in total, all of them in win32-nat.c:
>   - One to define MAXPATHLEN: Should really be done in
a proper way,
>     so should go away

I don't see this one in the current CVS; am I missing
something?

> The rest seems to be in i386-win32-tdep.c which is a
separate file.

I don't see this file, either, so I cannot comment on that.

> So what? the duplicates will never be linked into the
same build.  We
> already have duplicate code in targets that are alike,
one more cannot
> hurt.

I have to disagree on that. We're looking at duplicating 95%
of
the code. That means duplicating 95% of the maintenance. I
just
had a look at our code and I was surprised to see how little
code
is needed now to add support for native win32 support. If it
wasn't
for copyright issues, I'm thinking that I could be
submitting this
for inclusion with at most a day or two of work!

I'm happy to keep discussing this design aspect, but I think
we should
leave that discussion to when someone is ready to contribute
something.

> In my experience, mixing two different targets is
asking for trouble
> in the long run.

It depends. I somehow we could abstract out the code that
handles
IO in a way that it is transparent to the windows nat code,
just
the same way we introduced gdb_select, then we can share
everything.

> > In our merge, I counted 5 instances of
"ifdef/ifndef __MINGW32__
> 
> You need to count "ifdef __CYGWIN__" as
well.

Actually, currently all except one such ifdef are used as
"if on
windows". They look like this:

   #if defined(_WIN32) || defined(__CYGWIN__)

The only one is in gdbserver, to convert a solib path into
a
posix path when using cygwin.

> > in total, all of them in win32-nat.c:
> >   - One to define MAXPATHLEN: Should really be
done in a proper way,
> >     so should go away
> 
> I don't see this one in the current CVS; am I missing
something?

Yes, this is not necessary on cygwin, and mingw is not
supported,
so it's only in our (AdaCore) tree (and probably the mingw
tree as
well). It is:

    #ifdef __MINGW32__
      #define MAXPATHLEN PATH_MAX
    #endif

> > The rest seems to be in i386-win32-tdep.c which is
a separate file.
> 
> I don't see this file, either, so I cannot comment on
that.

Yes, this is normal, because this file is not part of the
FSF CVS.
It's a separate file that would only be needed for native
win32 support.
And now that I'm having a closer look at it, it looks like
this file
is a subset of the cygwin-tdep file, so I should probably
experiment
with the idea of replacing the win32-tdep file by the
cygwin-tdep one!

It's been a profitable discussion. Thanks a lot!

-- 
Joel

> Not sure who you're asking that, but, I'm not doing or
going to do
> anything, since you're already about to 

OK . I
don't have much time these days, and in fact, I wasn't
really supposed to dedicate the 4+ hours I have already
spent on
this, but since we seem to be on a roll, I'll try to spend
some
time on it next week to start the process and get us a
minimal
MinGW debugger.

-- 
Joel

Joel Brobecker wrote:
>> Not sure who you're asking that, but, I'm not doing
or going to do
>> anything, since you're already about to 
> 
> OK . I don't
have much time these days, and in fact, I wasn't
> really supposed to dedicate the 4+ hours I have already
spent on
> this, but since we seem to be on a roll, I'll try to
spend some
> time on it next week to start the process and get us a
minimal
> MinGW debugger.
> 

Nah, nah, na-na-naaah.  I've done it, and I said wouldn't 


Seriously, and rethinking a bit after sleep, it is safer to
do
it from scratch, so the copyright issues are cleared.

The initial changes are pretty mechanic, so, here goes.

What's done:

	- Added mingw.mh, mingw.mt as copies from the cygwin
files.
	- Updated configure.tgt to set gdb_target.
	- Disabled cygwin specific functionality in win32-nat.c. 
As can
	be seen, the changes are very small.
	- profs.h isn't needed anymore, since I've implemented
cygwin cross-core 
support a few weeks ago (in i386-cygwin-tdep.c).  The
include can be
	unconditionally removed.

What's next:

	Test with a mingw built libexpat to test dll support.

	win32_pid_to_exec_file:  Could be done with
GetModuleFileNameEx
	from PSAPI and/or with toolhelp.

	Rename a few things, which really aren't cygwin specific,
like:
		* cygwin_get_dr6 -> win32_get_dr6
		* i386-cygwin-tdep.h -> i386-win32-tdep.h
		* nm-cygwin.h -> nm-cygming.h

What's disabled:
	Use a shell to start the subprocess.

I'm sure there are other problems, but it is useable
already.

cygcheck.exe ./gdb.exe
.gdb.exe
   C:WINDOWSsystem32KERNEL32.dll
     C:WINDOWSsystem32ntdll.dll
   C:WINDOWSsystem32msvcrt.dll
   C:WINDOWSsystem32USER32.dll
     C:WINDOWSsystem32GDI32.dll
   C:WINDOWSsystem32WS2_32.DLL
     C:WINDOWSsystem32WS2HELP.dll
       C:WINDOWSsystem32ADVAPI32.dll
         C:WINDOWSsystem32RPCRT4.dll
           C:WINDOWSsystem32Secur32.dll

build-gdb_mingwgdb>gdb ./gdb.exe
GNU gdb 6.7.50-20071012-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/l
icenses/gpl.html>
This is free software: you are free to change and
redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type
"show copying"
and "show warranty" for details.
This GDB was configured as "mingw32"...
Setting up the environment for debugging gdb.
During symbol reading, struct/union type gets multiply
defined: struct type.
Breakpoint 1 at 0x40b513: file
../../gdb-server_submit/src/gdb/utils.c, line 817
.
Breakpoint 2 at 0x4185c6: file
../../gdb-server_submit/src/gdb/cli/cli-cmds.c, l
ine 199.
(top-gdb) start
Breakpoint 3 at 0x401309: file
../../gdb-server_submit/src/gdb/gdb.c, line 28.
Starting program:
D:cegccsfcegcccegccsrcbuild-gdb_mingwgdb/./gdb.exe
warning: Can not parse XML library list; XML support was
disabled at compile tim
e
main (argc=1, argv=0x3d24f0) at
../../gdb-server_submit/src/gdb/gdb.c:28
28        memset (&args, 0, sizeof args);

Cheers,
Pedro Alves

> Date: Sun, 14 Oct 2007 12:43:01 +0100
> From: Pedro Alves <pedro_alvesportugalmail.pt>
> CC: Eli Zaretskii <elizgnu.org>,  Kai.Tietzonevision.com, 
>  gdbsourceware.org
> 
> Nah, nah, na-na-naaah.  I've done it, and I said
wouldn't  

Thanks!

> What's disabled:
> 	Use a shell to start the subprocess.

This will lose support for redirection.  Perhaps we could
later add
something similar to what go32-nat.c did for DJGPP, to get
that back.