Re: [0/17] RFC: share minimal symbols across objfiles

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> The other major problem with this patch is that it makes it clear how
Tom> the BFD cache is fundamentally confused.
[...]
Tom> In sum, it is a mess and I am not sure what to do about it.  Mapping all
Tom> the needed debug sections is possible, but slow, and in the
Tom> multi-inferior case that seems to be a recipe for running out of memory.
Tom> (But we can run out of memory anyway and probably need some approach for
Tom> fixing this...)

Joel> I don't see a way out of this without involving BFD. If we could
Joel> register for notifications for a given bfd, I think it would allow
Joel> us to stay informed of what BFD has, so far, been doing behind
Joel> the scene...

I think the problem is deeper than just BFD, though I agree we probably
need to fix up BFD a bit somehow.  (Actually, I tend to think we should
just not use the BFD cache.)

We want to keep the fd open on the BFD, so that we can lazily map
sections.  If we close the fd, we might get different contents when we
reopen it.  This is actually a latent bug in gdb right now.

However, according to a comment in fork-child., we have to close the fd
in order to exec on some targets:

  /* On some systems an exec will fail if the executable is open.  */
  close_exec_file ();

This is the basic contradiction.


One idea I had is that, in this situation, we could eagerly map all the
sections we think we might ever want.

Another idea is to notice that the mtime has changed on reopen and
prevent us from mapping any more sections from that BFD.

It would be helpful to know which systems have this issue.  Maybe we
could make it a gdbarch parameter, so that we don't need workarounds on
more capable systems.

Tom