From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb@sources.redhat.com
Subject: Re: gdb and dlopen
Date: Wed, 17 Oct 2001 23:14:00 -0000
Message-id: <3BCE733E.1000304@cygnus.com>
References: <20011016161525.A1241@nevyn.them.org> <y3r8zebjbz8.wl@paladin.sgrail.com> <20011016213252.A8694@nevyn.them.org> <20011016220353.A9538@nevyn.them.org> <y3r669fj7bd.wl@paladin.sgrail.com> <3BCCF83F.8010401@cygnus.com> <20011017010849.A23345@nevyn.them.org> <20011017011923.A27536@nevyn.them.org> <1011017220745.ZM5792@ocotillo.lan> <3BCE0CA6.3040302@cygnus.com> <20011017200554.A28537@nevyn.them.org>
X-SW-Source: 2001-10/msg00189.html

> Remember, ptid_get_pid() is the messenger.  The real problem is 
>> elsewhere.  A bit like STREQ() in the symtab code.
> 
> 
> I don't understand what you mean by this.  We certainly need to get at
> the actual PID everywhere PIDGET () is being used, regardless of
> whether it could be hoisted out of loops.

To give an example, instead of accessing multiple thread objects 
simultaneously, GDB has a single global current thread state which it 
swaps in and out (using memcpy() and invalidate all).  As a consequence 
GDB spends its time doing this song and dance where is constantly and 
needlessly checks that the current single global thread is the correct 
current single global thread.

enjoy,
Andrew