From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] process/thread/lwp identifier mega-patch Date: Fri, 16 Feb 2001 14:19:00 -0000 Message-id: <3A8DA64D.958223C8@cygnus.com> References: <1001003083922.ZM18831@ocotillo.lan> <3A196C0E.B28DA29@cygnus.com> <1001120185800.ZM17272@ocotillo.lan> <3A1E4BE8.866BCBED@cygnus.com> <3A2748DF.206B4418@eazel.com> <1001204163129.ZM1315@ocotillo.lan> <3A8D3823.8CA8D470@cygnus.com> <1010216190651.ZM12055@ocotillo.lan> X-SW-Source: 2001-02/msg00310.html Kevin Buettner wrote: > > > Have you considered ignoring the problem? Well actually just > > accumulating a list of all the created threads and then, when GDB > > re-starts a target, deleting the lot? Yes, this will clearly not scale > > well in an application that creates then deletes millions of threads. > > Hopefully though, the benefits (such as improved performance) of having > > per thread objects will far out way this. > I think that your suggestion could be made to work, though it won't > be as simple as merely wiping out the thread list when GDB restarts > a target. The reason? Dangling pointers in static globals. > > E.g, in infrun.c, we have the following declaration: > > static int static int previous_inferior_pid; ARRG! > My patches change this declaration to: > > static struct ptid *previous_inferior_ptid; > > We would need to make sure this (and other static globals) are > reinitialized when the thread list is wiped out. Really nasty would be to enter each of those globals into a database and trash them at the same time as the thread pool is trashed. It might even be a tolerable workaround since those globals will eventually need to be deleted. > Another alternative is to make the execution context identifiers (or > ECIs for short) ``struct ptid'' instead of ``struct ptid *''. I.e, > make the ECI a struct instead of a pointer to a struct. The problem > with doing this is that the ECI's type can no longer be opaque. Again as an imtermediate step yes. > One can argue that if GDB accesses a defunct ECI (regardless of > implementation) at all, it is behaving incorrectly, because this > behavior is wrong regardless of whether the ECI is a struct or a > dangling pointer. It's just that it could be catastrophic if it's the > latter... > > So maybe it'd be best if we make sure that each and every ECI > occurence in the code is initialized properly when the thread list is > cleaned up. (In other words, I'm coming around to liking your > suggestion again...) You should probably look carefully at http://sources.redhat.com/ml/gdb/2001-02/msg00210.html . In that diagram, ``context'' roughly correspond to ``struct ptid *''. Andrew