From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21529 invoked by alias); 19 Nov 2001 23:11:48 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21508 invoked from network); 19 Nov 2001 23:11:46 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sourceware.cygnus.com with SMTP; 19 Nov 2001 23:11:46 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 7DB8E3D8B; Mon, 19 Nov 2001 18:11:46 -0500 (EST) Message-ID: <3BF991B1.50205@cygnus.com> Date: Thu, 08 Nov 2001 16:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Kevin Buettner , Kimball Thurston , gdb@sources.redhat.com Subject: Re: gdb and dlopen References: <3BCCF83F.8010401@cygnus.com> <20011017010849.A23345@nevyn.them.org> <3BCDA6CF.3000308@cygnus.com> <20011017141550.B10927@nevyn.them.org> <1011017195838.ZM5524@ocotillo.lan> <20011118144510.A19538@nevyn.them.org> <1011119170409.ZM16064@ocotillo.lan> <20011119141617.A20878@nevyn.them.org> <1011119193821.ZM16384@ocotillo.lan> <20011119163624.A25053@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00095.txt.bz2 > > I'm absolutely sure. Or at least, I was... when I tested this, it was > an obvious win. Now it is an obvious LOSS to turn on the cache. I'm > not sure why, so I'll have to investigate it later. In 5.0.90-cvs it > was a win and in current trunk it is a significant performance loss. > > This is in the context of a linuxthreads application. We do a > ridiculous, staggering amount of memory transfer in order to debug a > linuxthreads application, and parts of it are duplicated. Hmm, In the context of threads, trying to use the insn/data cache is cheating :-) The problem with threads is that GDB is constantly discarding its per thread information. Only to immediatly turn around and ask that that same information be re-created. GDB, when switching between threads, should retain that information in the the ``struct thread_info''. Even register information could be cached on a per-thread basis. See http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC37 enjoy, Andrew