From: Kris Warkentin <kewarken@qnx.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Daniel Jacobowitz <drow@false.org>,
"Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
Subject: Re: File locking of target executable
Date: Mon, 08 Mar 2004 17:55:00 -0000 [thread overview]
Message-ID: <404CB3E2.70301@qnx.com> (raw)
In-Reply-To: <4044F4C4.7040704@gnu.org>
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
>
>
prev parent reply other threads:[~2004-03-08 17:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 21:08 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=404CB3E2.70301@qnx.com \
--to=kewarken@qnx.com \
--cc=cagney@gnu.org \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox