[RFA] testsuite/gdb.base/fullname.exp fix

[RFA] testsuite/gdb.base/fullname.exp fix

[Pierre Muller]

  fullname.exp currently fails compilation
of windows targets because it tries to recompile
the executable, while it is still running under GDB.

  This patch exits GDB before recompilation.

Is this patch OK?


Pierre Muller
Pascal language support maintainer for GDB


PS:   Applying this patch to cygwin reveals a
problem concerning the set_unbuffered_mode object.
  This file is added as an additional object for linking,
but it is added without path information, and this
does not work inside fullname.exp test, as the 
working directory is moved here on purpose
to check GDB's ability to handle different 
relative path names for sources in debug information.

  Does anyone have an idea how to fix this?


2009-06-19  Pierre Muller  <muller@ics.u-strasbg.fr>

	* fullname.exp: Exit gdb before recompile as some operating systems
	lock the executable while it is running.

Index: src/gdb/testsuite/gdb.base/fullname.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/fullname.exp,v
retrieving revision 1.3
diff -u -p -r1.3 fullname.exp
--- src/gdb/testsuite/gdb.base/fullname.exp	3 Jan 2009 05:58:03 -0000
1.3
+++ src/gdb/testsuite/gdb.base/fullname.exp	19 Jun 2009 21:55:01 -0000
@@ -71,12 +71,12 @@ if { [gdb_breakpoint ${objdir}/${subdir}
     fail $msg
 }
 
+gdb_exit
 # Build the test executable using a relative path.
 if  { [gdb_compile "${subdir}/tmp-${srcfile}" "${binfile}" executable
{debug}] != "" } {
     return -1
 }
 
-gdb_exit
 gdb_start
 gdb_load ${binfile}
 
@@ -97,6 +97,7 @@ if { [gdb_breakpoint ${objdir}/${subdir}
     fail $msg
 }
 
+gdb_exit
 # Build the test executable using relative paths not relative to the
directory
 # we'll run GDB from.
 
@@ -108,7 +109,6 @@ if  { [gdb_compile "tmp-${srcfile}" "${t
 }
 cd $save_pwd
 
-gdb_exit
 gdb_start
 gdb_load ${binfile}
 

Re: [RFA] testsuite/gdb.base/fullname.exp fix

[Pedro Alves]

On Friday 19 June 2009 23:15:08, Pierre Muller wrote:
> 
>   fullname.exp currently fails compilation
> of windows targets because it tries to recompile
> the executable, while it is still running under GDB.

Might this be a new failure?  We have a few bfd_cache_close_all
calls around to prevent this.  Hmm, probably not.  Anyone
thinks we should do something to prevent this from happening? 
AFAICS, this particular case is something like:

> gdb filefoo

   (gdb opens the exec_file does things, and the calls bfd_cache_close_all.)

(gdb) b main << this reads file memory and reopens the bfd, nothing closes it.

Maybe we could always call bfd_cache_close_all after executing a
command...  Dunno, maybe that's going too far?  Probably will still be
defeated by the new dwarf memory mapped files support if that ever
is ported to Windows (I think Cygwin has now some magic to be able
to remove open files?  Maybe I'm dreaming.)

On Friday 19 June 2009 23:15:08, Pierre Muller wrote:
> 2009-06-19  Pierre Muller  <muller@ics.u-strasbg.fr>
> 
>         * fullname.exp: Exit gdb before recompile as some operating systems
>         lock the executable while it is running.
> 

This is OK if it isn't a new failure, and no one has replies to the
above questions, and if you move the "why" note from the changelong entry
to the .exp file.

The changelog header indicates "who" and "when".  The changelog entry
itself indicates "what".  The "why" belongs in the code.

-- 
Pedro Alves

Re: [RFA] testsuite/gdb.base/fullname.exp fix

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sun, 21 Jun 2009 02:27:47 +0100
> Cc: "Pierre Muller" <muller@ics.u-strasbg.fr>
> 
> (I think Cygwin has now some magic to be able
> to remove open files?  Maybe I'm dreaming.)

You can do that on Windows (only with NTFS, IIRC), but only if you use
CreateFile with the right flags to open the file.  Guess what the MS
runtime does in its emulation of `open', `fopen' and friends.

RE: [RFA] testsuite/gdb.base/fullname.exp fix

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé : Sunday, June 21, 2009 3:48 PM
> À : Pedro Alves
> Cc : gdb-patches@sourceware.org; muller@ics.u-strasbg.fr
> Objet : Re: [RFA] testsuite/gdb.base/fullname.exp fix
> 
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Sun, 21 Jun 2009 02:27:47 +0100
> > Cc: "Pierre Muller" <muller@ics.u-strasbg.fr>
> >
> > (I think Cygwin has now some magic to be able
> > to remove open files?  Maybe I'm dreaming.)
> 
> You can do that on Windows (only with NTFS, IIRC), but only if you use
> CreateFile with the right flags to open the file.  Guess what the MS
> runtime does in its emulation of `open', `fopen' and friends.

OK, now I understand:
  bfd seems to use these special flags,
so that after putting a breakpoint on main
you end up with two open handles on the executable
(I found that out by debugging gdb with itself)
and if you issue:
(gdb) shell rm gdb.base/fullname.exe
All works, in the sense that you are able to 
delete the file despite the open handles.
  But the problem is that if you try that:
(gdb) shell echo dummy > gdb.base/fullname.exe
you get:
sh: gdb.base/fullname.exe: Permission denied.

  So when trying to recompile fullname.exe
GNU ld first erases the existing binary (=> success)
and later tries to write the new binary (=> failure).

 What is the use of allowing delete operation and not write operation?

Pierre

Re: [RFA] testsuite/gdb.base/fullname.exp fix

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb-patches@sourceware.org>
> Date: Sun, 21 Jun 2009 18:45:18 +0200
> Content-Language: en-us
> 
> OK, now I understand:
>   bfd seems to use these special flags,

Actually, it probably doesn't.  See below.

> so that after putting a breakpoint on main
> you end up with two open handles on the executable
> (I found that out by debugging gdb with itself)
> and if you issue:
> (gdb) shell rm gdb.base/fullname.exe
> All works, in the sense that you are able to 
> delete the file despite the open handles.
>   But the problem is that if you try that:
> (gdb) shell echo dummy > gdb.base/fullname.exe
> you get:
> sh: gdb.base/fullname.exe: Permission denied.
> 
>   So when trying to recompile fullname.exe
> GNU ld first erases the existing binary (=> success)
> and later tries to write the new binary (=> failure).
> 
>  What is the use of allowing delete operation and not write operation?

That is all in the flags used when opening the file.  With the right
flags, write will also be permitted.  But I think for that we will
need our own emulation of `open' and friends, because the one in the
Windows runtime doesn't use them.  And even then, what NTFS does is
not fully Posix compliant: for example, the deleted file is still
visible in the filesystem, as long as at least one program has an open
handle for it, try running `ls' and you will see it.

So, on balance, I'd suggest to fix the testsuite not to expect this
Posix semantics, at least not on DOS/Windows.

RE: [RFA] testsuite/gdb.base/fullname.exp fix

[Pierre Muller]

> So, on balance, I'd suggest to fix the testsuite not to expect this
> Posix semantics, at least not on DOS/Windows.

Hi Eli,

  does that mean that I should make the change specific to Dos/Windows
targets? 
  I am not sure to know how to do that cleanly...

  Or should I just commit my patch as is,
the purpose of the test is completely different anyhow.


Pierre Muller
Pascal language support maintainer for GDB

Re: [RFA] testsuite/gdb.base/fullname.exp fix

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <pedro@codesourcery.com>, <gdb-patches@sourceware.org>
> Date: Fri, 26 Jun 2009 00:29:27 +0200
> 
> > So, on balance, I'd suggest to fix the testsuite not to expect this
> > Posix semantics, at least not on DOS/Windows.
> 
> Hi Eli,
> 
>   does that mean that I should make the change specific to Dos/Windows
> targets? 
>   I am not sure to know how to do that cleanly...

Can it be done for all platforms?  Did anyone object to doing so?

> the purpose of the test is completely different anyhow.

Sorry, I don't understand this part.  Can you explain?