Re: [0/9] BFD sharing

[Tom Tromey <tromey at redhat dot 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