From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2801 invoked by alias); 1 Nov 2002 18:44:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2764 invoked from network); 1 Nov 2002 18:44:00 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Nov 2002 18:44:00 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA1ILnw19355 for ; Fri, 1 Nov 2002 13:21:49 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA1Ihwf12878; Fri, 1 Nov 2002 13:43:58 -0500 Received: from localhost.localdomain (vpn50-53.rdu.redhat.com [172.16.50.53]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA1Ihvr11340; Fri, 1 Nov 2002 13:43:57 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id gA1Ihqq22821; Fri, 1 Nov 2002 11:43:52 -0700 Date: Fri, 01 Nov 2002 10:44:00 -0000 From: Kevin Buettner Message-Id: <1021101184351.ZM22820@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: why is gdb 5.2 so slow" (Nov 1, 1:32pm) References: <20021101013219.QDL1261.amsfep12-int.chello.nl@there> <20021101035218.GA14509@nevyn.them.org> <20021101133135.LDS1274.amsfep14-int.chello.nl@there> <3DC2967B.8050603@redhat.com> <20021101151639.GA3924@nevyn.them.org> <3DC2B1FE.3020908@redhat.com> <20021101181502.GA11243@nevyn.them.org> <3DC2C8CF.9080908@redhat.com> To: Andrew Cagney , Daniel Jacobowitz Subject: Re: why is gdb 5.2 so slow Cc: wim delvaux , gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00011.txt.bz2 On Nov 1, 1:32pm, Andrew Cagney wrote: > > In any case, this reminded me of something I keep forgetting. Modern > > kernels a ptrace-attached process can open the child's /proc//mem > > and read from it. Writing to it is disabled, and mmap is not > > implemented (oh the violence to the mm layer if that was allowed!). > > But reading from it is probably faster than PTRACE_PEEKTEXT. I'll > > investigate. > > Ah. How does solaris work then? On Solaris, /proc provides a complete debug interface. On Linux, it doesn't. Kevin