[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/15545] New: BFD cache loses cloexec flag
From: |
tromey at redhat dot com |
Subject: |
[Bug binutils/15545] New: BFD cache loses cloexec flag |
Date: |
Tue, 28 May 2013 18:20:31 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=15545
Bug ID: 15545
Summary: BFD cache loses cloexec flag
Product: binutils
Version: unspecified
Status: NEW
Severity: minor
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: tromey at redhat dot com
Created attachment 7047
--> http://sourceware.org/bugzilla/attachment.cgi?id=7047&action=edit
test program
Consider the attached program.
(Compile it and run it on itself to see the error.)
It opens a BFD using an explicit fd.
Then it calls bfd_cache_close_all.
Despite the comment in opncls.c:
/* If we opened the file by name, mark it cacheable; we can close it
and reopen it later. However, if a file descriptor was provided,
then it may have been opened with special flags that make it
unsafe to close and reopen the file. */
if (fd == -1)
(void) bfd_set_cacheable (nbfd, TRUE);
... this causes the fd to be closed. The BFD is not marked "cacheable"
but bfd_cache_close_all ignores this flag.
Then, the test program forces the BFD to be reopened.
Now, the "cacheable" flag is set.
All this is more subtle than it appears because I think GDB relies
on bfd_cache_close_all actually closing such fds.
One idea would be to simply remove the calls to bfd_cache_init from
opncls.c, but at the same time change gdb to add them.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug binutils/15545] New: BFD cache loses cloexec flag,
tromey at redhat dot com <=