This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [0/9] BFD sharing

On 07/30/2012 04:19 PM, Tom Tromey wrote:
> This series is a follow-on to my earlier minsym sharing series.
> Rather than attempt any sort of symbol sharing, which remains relatively
> hard, this series takes some baby steps in that direction.  Namely, it
> implements better sharing of BFDs, at least in the local file case, and
> it moves some obviously-shared data to be attached to the BFD rather
> than the objfile.
> This results in a bit less memory use; most noticeable in the
> multi-inferior case, though GDB is now a bit more efficient even in the
> single-inferior case, because currently multiple BFDs are made for the
> main file.

I've sent a few comments out to specific patches, but in general
this looks good to me.

> In my earlier series I was concerned about bad interactions between the
> BFD file descriptor cache and this code; but I think that the BFD file
> descriptor is broken even in today's GDB (there's even a PR with a
> real-life failure).

In general, we'll always need to account for limitations on the number of
open files and such, and also, even if we had an unlimited fd pool, we still
have the race between the program mapping a file, and gdb mapping some other,
due to the file on the filesystem having been updated meanwhile.  It seems to
me a complete solution to this would revolve around using some extra kernel
features like being able to re-open the exact same file the program has opened
like opening /proc/PID/exe instead of the path that symlink points to, and
some equivalent for shared libraries.  Then, the bfd cache/reopening of files
would not be a problem, as it'd always open the correct file (even if the file
had been unlinked from the filesystem already).

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]