Re: [rfa] Delete keep_thread_db

[Daniel Jacobowitz <drow@false.org>]

On Wed, Sep 08, 2004 at 07:00:00AM +0000, M.M. Kettenis wrote:
> Michael Snyder <msnyder@redhat.com> wrote:
> 
> > Andrew Cagney wrote:
> > > It would appear that, at one stage, this variable had something to do
> > > with corefiles, static programs and threads.  That's no longer the case
> > > so this deletes the stray global.
> > >
> > > Tested on FC3 with no regressions,
> > >
> > > Ok?
> > > Andrew
> >
> > I would have to defer to Mark Kettenis, since he added the
> > variable, and from the ChangeLogs, seems to be the only one
> > who's touched it.
> 
> The code defenitely was there to deal with static binaries.  Andrew,
> how did you come to the conclusion that it is no longer useful? 
> AFAIK there is no static threads test in the testsuite.

FYI, I believe this is what happened: keep_thread_db was added to deal
with static binaries.  It was necessary.  Core file debugging did not
work.

Core file debugging was then fixed, which broke static binaries.

keep_thread_db handles the fact that we only used the load-symfile
event to initialize thread_db, not any inferior_created event also.
If you use an observer after inferior creation for this, it won't be
necessary.  I don't see much point in removing it earlier than fixing
the bug; it's not "stray" yet, just broken.  But do whichever you want.

> Anyway, I don't care about this code anymore.  I've given up on
> debugging-with threads on Linux.  thread-db.c should renamed into
> linux-thread.c or somesuch.  It, and lin-lwp.c have become a mess of
> workarounds around workarounds around workarounds that probably only
> work if you run a specific combination of glibc and patched kernel.

I do care about this code.  It needs some major surgery, but it is
still useful (and, while fragile, not quite as fragile as all that). If
no one else is interested in maintaining it then I would like to.

-- 
Daniel Jacobowitz