* [0/17] RFC: share minimal symbols across objfiles @ 2011-12-14 21:05 Tom Tromey 2011-12-18 6:40 ` Joel Brobecker 2012-05-07 18:50 ` Tom Tromey 0 siblings, 2 replies; 9+ messages in thread From: Tom Tromey @ 2011-12-14 21:05 UTC (permalink / raw) To: gdb-patches This patch series changes gdb to allow some sharing of data across objfiles. In particular this series adds sharing of minimal symbols. The big idea here is that most data in an objfile is actually independent of the inferior. So, if multiple inferiors refer to the data, we should be able to read it just once and then share. This was discussed earlier: http://sourceware.org/ml/gdb-patches/2009-06/msg00668.html I wanted to post this patch series to get some comments on it. Although it does pass regression testing, it is not ready to check in yet. It has a few hacks and a few FIXMEs, and one un-finished project. One major problem with it right now is that because it duplicates the demangled_names_hash, it probably requires more memory at runtime for the single-inferior case than an unmodified gdb. I haven't tried to measure this. The other major problem with this patch is that it makes it clear how the BFD cache is fundamentally confused. The BFD cache maintains a limited number of open file descriptors for BFD objects. (Right now this limit is hard coded as 10, which is absurdly low.) BFD will automatically close file descriptors and will reopen the underlying file when needed. However, GDB has its own logic for reopening files -- it notices when the mtime has changed and will try to reread symbols at this point. Now consider the case where you have two inferiors accessing the same underlying file. Suppose further that one inferior is running, and the underlying file is changed and the user re-runs the second inferior. If the cache decides to reopen BFDs during this process, the first inferior could try to access invalid data (depending on when the various debug sections are mapped.) Also there are comments in gdb indicating that the BFDs must be closed, because on some operating systems keeping them open will mean that the file cannot be exec'd. In sum, it is a mess and I am not sure what to do about it. Mapping all the needed debug sections is possible, but slow, and in the multi-inferior case that seems to be a recipe for running out of memory. (But we can run out of memory anyway and probably need some approach for fixing this...) In contrast to my previous big patch, I split this one up as much as I thought reasonably possible. I haven't regtested all the patches individually, but I will probably do that at some point. Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [0/17] RFC: share minimal symbols across objfiles 2011-12-14 21:05 [0/17] RFC: share minimal symbols across objfiles Tom Tromey @ 2011-12-18 6:40 ` Joel Brobecker 2011-12-22 18:32 ` Tom Tromey 2012-05-07 18:50 ` Tom Tromey 1 sibling, 1 reply; 9+ messages in thread From: Joel Brobecker @ 2011-12-18 6:40 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > The other major problem with this patch is that it makes it clear how > the BFD cache is fundamentally confused. [...] > In sum, it is a mess and I am not sure what to do about it. Mapping all > the needed debug sections is possible, but slow, and in the > multi-inferior case that seems to be a recipe for running out of memory. > (But we can run out of memory anyway and probably need some approach for > fixing this...) I don't see a way out of this without involving BFD. If we could register for notifications for a given bfd, I think it would allow us to stay informed of what BFD has, so far, been doing behind the scene... -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [0/17] RFC: share minimal symbols across objfiles 2011-12-18 6:40 ` Joel Brobecker @ 2011-12-22 18:32 ` Tom Tromey 2011-12-22 19:25 ` Joel Brobecker ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Tom Tromey @ 2011-12-22 18:32 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [0/17] RFC: share minimal symbols across objfiles 2011-12-22 18:32 ` Tom Tromey @ 2011-12-22 19:25 ` Joel Brobecker 2012-01-04 15:17 ` [commit] delete corefile.c:close_exec_file (was: "Re: [0/17] RFC: share minimal symbols across objfiles") Joel Brobecker 2012-01-04 15:26 ` [0/17] RFC: share minimal symbols across objfiles Joel Brobecker 2 siblings, 0 replies; 9+ messages in thread From: Joel Brobecker @ 2011-12-22 19:25 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > 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. Just a wild guess: Windows, and hppa-hpux. I don't remember of any other filesystems that lock their files. Oddly, I remember seeing some messages on GNU/Linux machines which oddly looked like the kind of message you would get from a locking filesystem. But I don't remember the details, and it was racy anyway. I'm not completely sure about hppa-hpux, because I think you can still run a program that's locked by someone else, especially just for reading. The only thing that you can't do, IIRC, is delete (but you can move out of the way!). Unfortunately, I can't check anymore, because I no longer have access to hppa-hpux machines. I have been thinking of deprecating hppa-hpux, and maybe all of hppa if no one steps up. That might help a bit. I would love to deprecate Windows, but I won't even dare dream about it. Besides, it turns out that there are much much worse platforms than Windows, even if it often drives me crazy. If we can't determine where and how this is needed (maybe there's some archeological info to be dug out of CVS?), we might want to consider the idea of doing without it. And wait to see if it breaks someone. I know that Jerome and I have occasionaly looked at this sort of issue, but haven't always been succesful at making a proper patch. I can try digging things up, but it's getting late, so maybe tomorrow. -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* [commit] delete corefile.c:close_exec_file (was: "Re: [0/17] RFC: share minimal symbols across objfiles") 2011-12-22 18:32 ` Tom Tromey 2011-12-22 19:25 ` Joel Brobecker @ 2012-01-04 15:17 ` Joel Brobecker 2012-01-04 18:51 ` [commit] delete corefile.c:close_exec_file Tom Tromey 2012-01-04 15:26 ` [0/17] RFC: share minimal symbols across objfiles Joel Brobecker 2 siblings, 1 reply; 9+ messages in thread From: Joel Brobecker @ 2012-01-04 15:17 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 1320 bytes --] > 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. I reasearched this one, and I'm afraid that it predates CVS. But the good news is in corefile.c: | /* The exec file must be closed before running an inferior. | If it is needed again after the inferior dies, it must | be reopened. */ | | void | close_exec_file (void) | { | #if 0 /* FIXME */ | if (exec_bfd) | bfd_tempclose (exec_bfd); | #endif | } Ha ha ha! The code has been commented out side Jul 07, 1999 (the revision history says: "import gdb-1999-07-07 post reformat"). Attached is the patch that I just checked in as obvious. Does it simplify a bit your work? gdb/ChangeLog: * corefile.c (close_exec_file): Delete. (reopen_exec_file): Remove commented out code that seems related to close_exec_file, which is being deleted here. * inferior.h (close_exec_file): Delete. * fork-child.c (fork_inferior): Remove call to fork_inferior. Tested by rebuilding GDB on x86_64-linux. Testsuite running, but how can it regress? -- Joel [-- Attachment #2: 0001-Get-rid-of-corefile.c-close_exec_file.patch --] [-- Type: text/x-diff, Size: 3231 bytes --] From 36ac6184edccab0330e7d87a23f02e97f22b8ae9 Mon Sep 17 00:00:00 2001 From: Joel Brobecker <brobecker@adacore.com> Date: Wed, 4 Jan 2012 19:07:24 +0400 Subject: [PATCH] Get rid of corefile.c:close_exec_file The body of this function has been commented out since Jul 1999, and thus seems unnecessary. While at it, remove some commented out code that seems to be related to the function being deleted. gdb/ChangeLog: * corefile.c (close_exec_file): Delete. (reopen_exec_file): Remove commented out code that seems related to close_exec_file, which is being deleted here. * inferior.h (close_exec_file): Delete. * fork-child.c (fork_inferior): Remove call to fork_inferior. --- gdb/ChangeLog | 8 ++++++++ gdb/corefile.c | 18 ------------------ gdb/fork-child.c | 3 --- gdb/inferior.h | 2 -- 4 files changed, 8 insertions(+), 23 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 8bdb758..445e931 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,13 @@ 2012-01-04 Joel Brobecker <brobecker@adacore.com> + * corefile.c (close_exec_file): Delete. + (reopen_exec_file): Remove commented out code that seems related + to close_exec_file, which is being deleted here. + * inferior.h (close_exec_file): Delete. + * fork-child.c (fork_inferior): Remove call to fork_inferior. + +2012-01-04 Joel Brobecker <brobecker@adacore.com> + * ada-lang.c: #include "cli/cli-utils.h". (get_selections): Use skip_spaces. (ada_get_next_arg): Use skip_spaces and skip_to_space. diff --git a/gdb/corefile.c b/gdb/corefile.c index c07447b..1741e9c 100644 --- a/gdb/corefile.c +++ b/gdb/corefile.c @@ -132,26 +132,9 @@ specify_exec_file_hook (void (*hook) (char *)) deprecated_exec_file_display_hook = hook; } -/* The exec file must be closed before running an inferior. - If it is needed again after the inferior dies, it must - be reopened. */ - -void -close_exec_file (void) -{ -#if 0 /* FIXME */ - if (exec_bfd) - bfd_tempclose (exec_bfd); -#endif -} - void reopen_exec_file (void) { -#if 0 /* FIXME */ - if (exec_bfd) - bfd_reopen (exec_bfd); -#else char *filename; int res; struct stat st; @@ -175,7 +158,6 @@ reopen_exec_file (void) bfd_cache_close_all (); do_cleanups (cleanups); -#endif } \f /* If we have both a core file and an exec file, diff --git a/gdb/fork-child.c b/gdb/fork-child.c index cba91f9..3b8da49 100644 --- a/gdb/fork-child.c +++ b/gdb/fork-child.c @@ -272,9 +272,6 @@ fork_inferior (char *exec_file_arg, char *allargs, char **env, argv[3] = (char *) 0; } - /* On some systems an exec will fail if the executable is open. */ - close_exec_file (); - /* Retain a copy of our environment variables, since the child will replace the value of environ and if we're vforked, we have to restore it. */ diff --git a/gdb/inferior.h b/gdb/inferior.h index f9b3656..f05789f 100644 --- a/gdb/inferior.h +++ b/gdb/inferior.h @@ -154,8 +154,6 @@ extern void fetch_inferior_event (void *); extern void init_wait_for_inferior (void); -extern void close_exec_file (void); - extern void reopen_exec_file (void); /* The `resume' routine should only be called in special circumstances. -- 1.7.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [commit] delete corefile.c:close_exec_file 2012-01-04 15:17 ` [commit] delete corefile.c:close_exec_file (was: "Re: [0/17] RFC: share minimal symbols across objfiles") Joel Brobecker @ 2012-01-04 18:51 ` Tom Tromey 2012-01-05 3:03 ` Joel Brobecker 0 siblings, 1 reply; 9+ messages in thread From: Tom Tromey @ 2012-01-04 18:51 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Joel> Ha ha ha! Indeed :) Joel> Attached is the patch that I just checked in as obvious. Does it Joel> simplify a bit your work? Yes, I think it does, but there are still a lot of bfd_cache_close_all calls to contend with. Maybe these hid the fact that close_exec_file did nothing. I imagine at least some of these calls are needed on some platforms. I haven't tried to test this yet. Some of the calls seem a bit weird. E.g., the one in symbol_file_add_with_addrs_or_offsets, from this thread: http://sourceware.org/ml/gdb-patches/2004-07/msg00439.html I'm still thinking about what options we have. Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [commit] delete corefile.c:close_exec_file 2012-01-04 18:51 ` [commit] delete corefile.c:close_exec_file Tom Tromey @ 2012-01-05 3:03 ` Joel Brobecker 0 siblings, 0 replies; 9+ messages in thread From: Joel Brobecker @ 2012-01-05 3:03 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > Yes, I think it does, but there are still a lot of bfd_cache_close_all > calls to contend with. Maybe these hid the fact that close_exec_file > did nothing. Ah, yes, of course. These, I know we're responsible for some of them. And there is at least one that we tried to contribute, wasn't quite right, and then fell on the side. I think. But we should be able to find the history of each one. > I imagine at least some of these calls are needed on some platforms. > I haven't tried to test this yet. Yes, I am pretty sure they are, unfortunately. > Some of the calls seem a bit weird. E.g., the one in > symbol_file_add_with_addrs_or_offsets, from this thread: > > http://sourceware.org/ml/gdb-patches/2004-07/msg00439.html I reconnected the thread in the archives (a real shame that the threading does not work across months...): [RFA] win32: bfd_cache_close after kill http://www.sourceware.org/ml/gdb-patches/2004-05/msg00678.html http://www.sourceware.org/ml/gdb-patches/2004-05/msg00756.html http://www.sourceware.org/ml/gdb-patches/2004-06/msg00008.html http://www.sourceware.org/ml/gdb-patches/2004-06/msg00512.html In the process of doing so, I found: [commit] Close the executable after it exits http://sourceware.org/ml/gdb-patches/2008-04/msg00706.html (from DanielJ) [patch] release handle on object files after program exits http://sourceware.org/ml/gdb-patches/2009-04/msg00074.html (from yours truly) I think it should be reasonably easy to find the history of each of them should we need to. Based on the few messages I glanced at, it seems that they deal with unlocking the exe after program exits or gets killed by GDB. The main platform involved is Windows, with HP-UX being mentioned as well... -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [0/17] RFC: share minimal symbols across objfiles 2011-12-22 18:32 ` Tom Tromey 2011-12-22 19:25 ` Joel Brobecker 2012-01-04 15:17 ` [commit] delete corefile.c:close_exec_file (was: "Re: [0/17] RFC: share minimal symbols across objfiles") Joel Brobecker @ 2012-01-04 15:26 ` Joel Brobecker 2 siblings, 0 replies; 9+ messages in thread From: Joel Brobecker @ 2012-01-04 15:26 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > 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. Is exec-bfd the only objfile with the issue? To me, the answer seems an obvious NOT, but you never know. Going back to this question, I'm just going to repeat as a reminder that the only systems I remember having file-locking problems that forced us to close fds are pa-hpux, and Windows in general. The sort of issue I remember seeing was trying to update the executable while the program is opened by GDB and yet not running. I still haven't gotten to te bottom of some failures see in GDB on GNU/Linux systems as well, with symptoms very similar to a file-locking issue. I started looking at them when I had a free second or two, but I could never make sense out of them in the short amount of time I could dedicate. The gdbarch parameter seems risky to me, it's often more a property of the filesystem than a property of the platform... Having spent a fair amount of time on many of these exotic platforms, I would be happy to try helping a bit. -- Joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [0/17] RFC: share minimal symbols across objfiles 2011-12-14 21:05 [0/17] RFC: share minimal symbols across objfiles Tom Tromey 2011-12-18 6:40 ` Joel Brobecker @ 2012-05-07 18:50 ` Tom Tromey 1 sibling, 0 replies; 9+ messages in thread From: Tom Tromey @ 2012-05-07 18:50 UTC (permalink / raw) To: gdb-patches >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Tom> This patch series changes gdb to allow some sharing of data across Tom> objfiles. In particular this series adds sharing of minimal symbols. Tom> The big idea here is that most data in an objfile is actually Tom> independent of the inferior. So, if multiple inferiors refer to the Tom> data, we should be able to read it just once and then share. I recently thought of a problem with this patch series. If an inferior uses dlmopen to load a .so multiple times, then the patched gdb will fail. The problem is that the series (in particular patch #14) assumes that a given minimal symbol appears a single time in the inferior; but with dlmopen it may appear multiple times. I'm still not sure of the best way to fix this problem. One idea is to have the various searching functions return a {minsym, objfile} pair, rather than just a pointer to the minimal symbol. This would be a pretty big (if mostly mechanical) patch, though. Another approach I've considered a little is having gdb create relocated minimal symbols on the fly, and cache them per-objfile. Then the lookup functions can always return these cached, relocated minsyms. This uses a bit more memory (but presumably not too bad -- most symbols aren't used); but it is also obviously just a hack to work around a design flaw. On the whole I think the first idea is cleaner. Maybe there is some other approach that would work. I think I'd like to resurrect parts of this series (the BFD refcounting and filename changes, and registry.h) and put them in, since they are reasonable (IMO :) cleanups in their own right. Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-05-07 18:50 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-14 21:05 [0/17] RFC: share minimal symbols across objfiles Tom Tromey 2011-12-18 6:40 ` Joel Brobecker 2011-12-22 18:32 ` Tom Tromey 2011-12-22 19:25 ` Joel Brobecker 2012-01-04 15:17 ` [commit] delete corefile.c:close_exec_file (was: "Re: [0/17] RFC: share minimal symbols across objfiles") Joel Brobecker 2012-01-04 18:51 ` [commit] delete corefile.c:close_exec_file Tom Tromey 2012-01-05 3:03 ` Joel Brobecker 2012-01-04 15:26 ` [0/17] RFC: share minimal symbols across objfiles Joel Brobecker 2012-05-07 18:50 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).