Re: Support of gdb for Windows 64 native systems

Daniel Jacobowitz wrote on 11.10.2007 16:23:48:

> On Thu, Oct 11, 2007 at 04:18:40PM +0200, Kai Tietz
wrote:
> > Hmm, wouldn't this be a good chance to bring back
the mingw32 support 
to 
> > the FSF GDB tree ? For sure most of those patches
for i?86-mingw are 
> > needed for 64-bit mingw32 too (especially the
file-I/O and shared 
object 
> > stuff). But the calling convention for 64-bit is
more simple than for 
the 
> > 32-bit version.
> > Do you think there is no chance for this support
?
> 
> All it needs is someone who is interested to do the
work.  And we
> can't start from the MinGW project's patches, because
they are not
> assigned to the FSF (I don't know why not but that's
what I was told).

Ok, I questioned mingw, why they did not assigned those
patches to the 
FSF. But on the otherhand, I would do this work (I need to
make an other 
FSF assignement for gdb), if I get some advice. Until now, I
haven't 
worked with gdb sources, so the architecture is a bit
strange for me. Is 
there a good documentation about the subject how to add an
new target 
(TUI) ?

Cheers,
 i.A. Kai Tietz

|  (_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------
------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 -
www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs
Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg -
Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

On Thu, Oct 11, 2007 at 04:47:28PM +0200, Kai Tietz wrote:
> Ok, I questioned mingw, why they did not assigned those
patches to the 
> FSF. But on the otherhand, I would do this work (I need
to make an other 
> FSF assignement for gdb), if I get some advice. Until
now, I haven't 
> worked with gdb sources, so the architecture is a bit
strange for me. Is 
> there a good documentation about the subject how to add
an new target 
> (TUI) ?

What does the TUI have to do with it?  TUI in particular is
troublesome for mingw because of the lack of good curses
libraries.

There's documentation in the internals manual.  For a native
Windows
target, you'd have to talk to Chris about how to avoid
duplicating
or complicating the Cygwin support.

-- 
Daniel Jacobowitz
CodeSourcery

> I'm not surprised, in particular because I've seen the
patches applied
> by the MinGW folks to produce a native MinGW port. 
Personally, I
> still think that at this magnitude of ifdef'ing we can
certainly
> justify two different targets.

Yes, it's less clear at this point. Perhaps we can reduce
further
the differences. As this thread has shown me, the chopping I
have
already done was not nearly enough...

> But this is not my call, and the prospects of finally
having MinGW
> support part of the official repository are so
thrilling for me that
> I'd hate if this argument would stand in the way.

I'm like you, if keeping them separate is what the group
decides,
that's also fine with me. Might be more like Chris' call.

Note however, it's not a done deal yet, because the patches
are slightly
tainted by copyright assignment issues. Some of the changes
have been
replaced by my work, so you can say they are AdaCore's, but
some others
have been imported straight from the MinGW patch. Let's try
to reduce it
as much as we can, and then I'll try to track down all the
authors of
the pieces that are left.

> >  #include <sys/param.h>
> > +#ifdef __MINGW32__
> > +  #define MAXPATHLEN PATH_MAX
> > +#endif
> 
> What am I missing here?  Are you perhaps targeting some
old MinGW
> versions that didn't have that in sys/param.h?

You're right - it turns out this one is not needed anymore.

> > +#ifndef HAVE_CYGWIN_CONV_TO_WIN32_PATH
> > +/* A basic replacement implementation for
cygwin_conv_to_win32_path ()
> > +   when not available (basically, when building
using a MinGW compiler).  */
> > +static void
> > +cygwin_conv_to_win32_path (const char *path, char
*win32_path)
> > +{
> > +  strcpy (win32_path, path);
> > +}
> > +#endif
> 
> I hope these will be eventually rewritten to do
something useful,
> otherwise that's a gratuitous ugliness.

The thing is that they don't need to do anything useful.
The PATH is already in win32 format.

> > +#ifdef _WIN32
> > +  /* The executable must not be closed because it
will not been possible to
> > +     reopen it later under Windows NT if this
executable is the one being
> > +     debugged. */
> > +
> > +  if (strstr (name, ".exe") != NULL)
> > +    sym_bfd->cacheable = FALSE;
> > +  else
> > +#endif
> 
> Doesn't Cygwin define _WIN32?  If it does, why do you
need to
> condition this fragment?

I wasn't the author of this change, I think it was Jerome
Guitton.
Nonetheless, I think that the intent was to try to avoid
unexpected
impact on other platforms. The #ifdef can certainly be
removed.

In fact, this change is not necessary at all, it's just a
convenience in
the following scenario (IIRC): After having debugged your
exe, you found
the bug, so you use the "kill" command to kill the
process and, while
leaving the debugger up and running, try to rebuild your
program. Because
GDB still has a handle on the EXE, the windows filesystem
doesn't let you
delete the file to replace with the new one. So this can be
handled as
a separate patch.

I think at this point that the next thing to do is to review
carefully
the patch, and evaluate what is needed and what isn't
anymore. Then
we can tackle the issue of copyright assignement, and then
finally
submit/discuss a new patch.

-- 
Joel

Joel Brobecker wrote:

> I think at this point that the next thing to do is to
review carefully
> the patch, and evaluate what is needed and what isn't
anymore. Then
> we can tackle the issue of copyright assignement, and
then finally
> submit/discuss a new patch.
> 

That is IMHO, the wrong way to do it.  The copyright
assignment
should be resolved first, before everyone looks into the
patches.
Otherwise, it taints whoever looks at the thread, and
inhibits that
someone from redoing it from scratch, if the copyright
issues end up
unresolved doesn't it?

I propose goind the other way around.  Start by adding the
needed configury
bits needed, a mingw.mt file, and disabling the cygwin
specific bits in
win32-nat.c around #ifdef __CYGWIN__ blocks.  I'd like to
keep the
changes mostly in sync with gdbserver/win32-low.c too, but
that shouldn't
be a priority.  We can then peacewise enhance the mingw port
and bring
its features up.  We can even forget about stdio redirection
and
environment passing to the inferior on the first step - that
leaves mostly
only path handling to care about - really, look at
gdbserver/win32-low.c (#ifdef USE_WIN32API).

Cheers,
Pedro Alves

> Date: Sat, 13 Oct 2007 18:36:28 +0100
> From: Pedro Alves <pedro_alvesportugalmail.pt>
> CC: Eli Zaretskii <elizgnu.org>,  Kai.Tietzonevision.com, 
>  gdbsourceware.org
> 
> Joel Brobecker wrote:
> 
> > I think at this point that the next thing to do is
to review carefully
> > the patch, and evaluate what is needed and what
isn't anymore. Then
> > we can tackle the issue of copyright assignement,
and then finally
> > submit/discuss a new patch.
> > 
> 
> That is IMHO, the wrong way to do it.  The copyright
assignment
> should be resolved first, before everyone looks into
the patches.
> Otherwise, it taints whoever looks at the thread, and
inhibits that
> someone from redoing it from scratch, if the copyright
issues end up
> unresolved doesn't it?

If someone describes the changes, and someone else codes
them, there's
no need to resolve the copyright issues.  Copyright only
deals with
verbatim copying of the code; ideas cannot be copyrighted.

However, I agree that having everyone look at the patches is
not a
very good idea, since it will make it harder not to copy
code.

> I propose goind the other way around.  Start by adding
the needed configury
> bits needed, a mingw.mt file, and disabling the cygwin
specific bits in
> win32-nat.c around #ifdef __CYGWIN__ blocks.  I'd like
to keep the
> changes mostly in sync with gdbserver/win32-low.c too,
but that shouldn't
> be a priority.  We can then peacewise enhance the mingw
port and bring
> its features up.

We don't need to go that slow.

Eli Zaretskii wrote:

>> I propose goind the other way around.  Start by
adding the needed configury
>> bits needed, a mingw.mt file, and disabling the
cygwin specific bits in
>> win32-nat.c around #ifdef __CYGWIN__ blocks.  I'd
like to keep the
>> changes mostly in sync with gdbserver/win32-low.c
too, but that shouldn't
>> be a priority.  We can then peacewise enhance the
mingw port and bring
>> its features up.
> 
> We don't need to go that slow.
> 

Sure, but it's the natural way to introduce the new target. 
I'm not saying
it should be done slowly timewise.  I'm saying it should
start from the
bottom up patchwise.  It can be submitted in a patch series
in the
same minute for all I care.  The point is, we shouldn't be
looking at
a patch and deciding what we *don't* need; we should be
looking at
what we have, and deciding what we *do* need.

-- 
Cheers,
Pedro Alves