From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25655 invoked by alias); 1 Nov 2002 18:32:53 -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 25605 invoked from network); 1 Nov 2002 18:32:51 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Nov 2002 18:32:51 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2B8F73CB1; Fri, 1 Nov 2002 13:32:48 -0500 (EST) Message-ID: <3DC2C8CF.9080908@redhat.com> Date: Fri, 01 Nov 2002 10:32:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: wim delvaux , gdb@sources.redhat.com Subject: Re: why is gdb 5.2 so slow 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00010.txt.bz2 >> [my guess] If the condition fails, we need to thread-hop. If the >> condition succeeds we need to stop all threads anyway. > > > Oh, blast it. So we can't use this for general conditional > breakpoints. If the condition is true we stop all threads before > giving a prompt; if the condition is false we stop all threads in order > to step over the breakpoint. Well, the conditional expression could be pushed down into the target (aka kernel) as byte codes. Part of that introspect stuff. That way the kernel could co-ordinate it. > We could do thread-specific breakpoints hit by the wrong thread this > way... and thread-specific conditional breakpoints hit by the right > thread but with the condition false could _probably_ be done this way > but implementing it would be complicated. But GDB needs to do thread specific breakpoints anyway :-) > Now, thread-specific breakpoints hit by the wrong thread could be used > to speed up "next"/software-single-step... > >> Uli (glibc), KevinB, MichaelS, and I happened to be in the same room and >> talked about this. /procfs was suggested as an alternative path. For >> ptrace() Uli indicated something about running out of register arguments >> to use across a system call. > > > I don't know what he's referring to... wait... request, pid, len, > target address, buffer. x86 can only do four. Crappy but it could be > worked around. > > 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? >> Apparently that guarentee is comming. Solaris, for instance, is moving >> back to 1:1. My instinct is that reduceing the system calls will make a >> far greater improvement than trimming back glibc. > > > Well, I'd hate to lose NGPT support; like it or not a lot of people > (especially in the carrier-grade Bingo! > space) are starting to use it. At the > same time we don't need to be using the heavyweight interface when it > isn't needed. (By NGPT I'm guessing that you mean N:M threads) I don't think GDB will loose that - it will always need to support things like N:1. It's just that for 1:1 threads, the implementation can be shaved down to nothing. Andrew