This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [0/9] BFD sharing
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 01 Aug 2012 14:40:41 -0600
- Subject: Re: [0/9] BFD sharing
- References: <87vch55la9.fsf@fleche.redhat.com> <50180C93.60908@redhat.com>
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Tom> In my earlier series I was concerned about bad interactions between the
Tom> BFD file descriptor cache and this code; but I think that the BFD file
Tom> descriptor is broken even in today's GDB (there's even a PR with a
Tom> real-life failure).
Pedro> In general, we'll always need to account for limitations on the
Pedro> number of open files and such, and also, even if we had an
Pedro> unlimited fd pool, we still have the race between the program
Pedro> mapping a file, and gdb mapping some other, due to the file on
Pedro> the filesystem having been updated meanwhile. It seems to me a
Pedro> complete solution to this would revolve around using some extra
Pedro> kernel features like being able to re-open the exact same file
Pedro> the program has opened like opening /proc/PID/exe instead of the
Pedro> path that symlink points to, and some equivalent for shared
Pedro> libraries. Then, the bfd cache/reopening of files would not be a
Pedro> problem, as it'd always open the correct file (even if the file
Pedro> had been unlinked from the filesystem already).
That's an interesting idea. I wonder if we can make it happen.
Lately I have been thinking of undoing the lazy-mapping change, and
having gdb just eagerly map all the debuginfo sections again. Then the
BFD cache basically would not matter. The downside is that we may use a
lot of address space mapping things we won't ever need; plus some
startup time cost.
Tom