* File locking of target executable
@ 2004-03-02 21:08 Kris Warkentin
2004-03-02 20:40 ` Kris Warkentin
0 siblings, 1 reply; 6+ messages in thread
From: Kris Warkentin @ 2004-03-02 21:08 UTC (permalink / raw)
To: Gdb@Sources.Redhat.Com
I've observed (on Windows at least) that when I'm debugging an
executable, I can't delete it. Just having it the executable loaded in
gdb is insufficient; it actually has to be running. I didn't see
anything on a casual sniff through the source but perhaps I'm missing
some sort of lock procedure.
This comes up in the context of Eclipse: if you're debugging a project
and try to rebuild, the make fails when it can't unlink the target app.
It looks like under some circumstances gdb might use memory mapped
files...could that be the culprit?
cheers,
Kris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: File locking of target executable
2004-03-02 21:08 File locking of target executable Kris Warkentin
@ 2004-03-02 20:40 ` Kris Warkentin
2004-03-02 20:44 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Kris Warkentin @ 2004-03-02 20:40 UTC (permalink / raw)
To: Gdb@Sources.Redhat.Com
Argh. I always see the answer AFTER I mail to the mailing list. Looks
like Windows itself won't let a binary be removed if it's executing.
The problem report states that this is happening in the remote case but
I just checked and it doesn't seem to be. Must be an error in the bug
report.
cheers,
Kris
Kris Warkentin wrote:
> I've observed (on Windows at least) that when I'm debugging an
> executable, I can't delete it. Just having it the executable loaded
> in gdb is insufficient; it actually has to be running. I didn't see
> anything on a casual sniff through the source but perhaps I'm missing
> some sort of lock procedure.
>
> This comes up in the context of Eclipse: if you're debugging a project
> and try to rebuild, the make fails when it can't unlink the target
> app. It looks like under some circumstances gdb might use memory
> mapped files...could that be the culprit?
>
> cheers,
>
> Kris
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: File locking of target executable
2004-03-02 20:40 ` Kris Warkentin
@ 2004-03-02 20:44 ` Daniel Jacobowitz
2004-03-02 20:52 ` Christopher Faylor
2004-03-02 20:55 ` Andrew Cagney
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-03-02 20:44 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com
On Tue, Mar 02, 2004 at 03:41:24PM -0500, Kris Warkentin wrote:
> Argh. I always see the answer AFTER I mail to the mailing list. Looks
> like Windows itself won't let a binary be removed if it's executing.
> The problem report states that this is happening in the remote case but
> I just checked and it doesn't seem to be. Must be an error in the bug
> report.
It can happen in the remote case too sometimes - I don't think Windows
lets you delete an open file either.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: File locking of target executable
2004-03-02 20:44 ` Daniel Jacobowitz
@ 2004-03-02 20:52 ` Christopher Faylor
2004-03-02 20:55 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Christopher Faylor @ 2004-03-02 20:52 UTC (permalink / raw)
To: Gdb@Sources.Redhat.Com; +Cc: Kris Warkentin
On Tue, Mar 02, 2004 at 03:44:03PM -0500, Daniel Jacobowitz wrote:
>On Tue, Mar 02, 2004 at 03:41:24PM -0500, Kris Warkentin wrote:
>>Argh. I always see the answer AFTER I mail to the mailing list. Looks
>>like Windows itself won't let a binary be removed if it's executing.
>>The problem report states that this is happening in the remote case but
>>I just checked and it doesn't seem to be. Must be an error in the bug
>>report.
>
>It can happen in the remote case too sometimes - I don't think Windows
>lets you delete an open file either.
It depends on the version of Windows and it depends on how the file is
being deleted.
Cygwin uses delete-on-last-close type of semantics in unlink() so that
should work in cases where cygwin is being used. If you're not using
Cygwin, but you are using Windows NT, you could investigate using the
DELETE_ON_CLOSE argument to CreateFile as a method for (eventually)
deleting an open file.
cgf
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: File locking of target executable
2004-03-02 20:44 ` Daniel Jacobowitz
2004-03-02 20:52 ` Christopher Faylor
@ 2004-03-02 20:55 ` Andrew Cagney
2004-03-08 17:55 ` Kris Warkentin
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2004-03-02 20:55 UTC (permalink / raw)
To: Daniel Jacobowitz, Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com
> On Tue, Mar 02, 2004 at 03:41:24PM -0500, Kris Warkentin wrote:
>
>>> Argh. I always see the answer AFTER I mail to the mailing list. Looks
>>> like Windows itself won't let a binary be removed if it's executing.
>>> The problem report states that this is happening in the remote case but
>>> I just checked and it doesn't seem to be. Must be an error in the bug
>>> report.
>
>
> It can happen in the remote case too sometimes - I don't think Windows
> lets you delete an open file either.
Look at bfd_cache_close(), which may solve the problem.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: File locking of target executable
2004-03-02 20:55 ` Andrew Cagney
@ 2004-03-08 17:55 ` Kris Warkentin
0 siblings, 0 replies; 6+ messages in thread
From: Kris Warkentin @ 2004-03-08 17:55 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com
This is an interesting and subtle problem. Looks like cygwin's fopen()
command does some sort of funky file-locking that open() does not. If I
compile my fopen() test with -mno-cygwin, I can delete the target file
without difficulty so the fact that bfd uses fopen() would seem to be
the reason you can't delete an executable which is being debugged.
Since our ultimate aim is to build all of our tools without cygwin, this
problem should eventually solve itself, assuming I can find my way down
the long and winding road of getting gdb to build with mingw32. That
seems a more attractive solution that trying to replace all the FILE *
with file descriptors. I think a FILE * is more portable than a file
descriptor anyway.
cheers,
Kris
Andrew Cagney wrote:
>> On Tue, Mar 02, 2004 at 03:41:24PM -0500, Kris Warkentin wrote:
>>
>>>> Argh. I always see the answer AFTER I mail to the mailing list.
>>>> Looks like Windows itself won't let a binary be removed if it's
>>>> executing. The problem report states that this is happening in the
>>>> remote case but I just checked and it doesn't seem to be. Must be
>>>> an error in the bug report.
>>>
>>
>>
>> It can happen in the remote case too sometimes - I don't think Windows
>> lets you delete an open file either.
>
>
> Look at bfd_cache_close(), which may solve the problem.
>
> Andrew
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-03-08 17:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-02 21:08 File locking of target executable Kris Warkentin
2004-03-02 20:40 ` Kris Warkentin
2004-03-02 20:44 ` Daniel Jacobowitz
2004-03-02 20:52 ` Christopher Faylor
2004-03-02 20:55 ` Andrew Cagney
2004-03-08 17:55 ` Kris Warkentin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox