From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27256 invoked by alias); 26 Mar 2003 02:14:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27246 invoked from network); 26 Mar 2003 02:14:25 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 26 Mar 2003 02:14:25 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2Q2EPsJ003645 for ; Tue, 25 Mar 2003 18:14:25 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 25 Mar 2003 18:14:17 -0800 Received: from apple.com (inghji.apple.com [17.201.22.240]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h2Q2EOt13146; Tue, 25 Mar 2003 18:14:24 -0800 (PST) Date: Wed, 26 Mar 2003 02:14:00 -0000 Subject: Re: [rfc breakpoint] Catch exceptions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: gdb-patches@sources.redhat.com To: Daniel Jacobowitz From: Jim Ingham In-Reply-To: <20030326000354.GA13823@nevyn.them.org> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00510.txt.bz2 On Tuesday, March 25, 2003, at 04:03 PM, Daniel Jacobowitz wrote: > On Tue, Mar 25, 2003 at 03:51:32PM -0800, Jim Ingham wrote: >> One thing we had to worry about at least on Mac OS X is that we don't >> use a shared libstdc++, rather every shlib that uses C++ get its own >> copy of all the libsupc++ code. So there are actually many copies of >> __cxa__begin_catch hanging around. To do this properly, you have to >> search exhaustively for these symbols, not just take the first hit. >> Moreover, you have to redo it on every shared library load, or you >> will >> miss some. This still might bite you on other systems, for instance >> if >> out of paranoia somebody had linked their shlib or executable >> statically to libstdc++.a (so they wouldn't get bit by changing ABI >> issues or whatever). >> >> BTW. The more general problem of a symbol resolving to multiple >> instances - for instance setting file:line breakpoints in inlined >> functions or template method defn's - is something we need to address. >> It really ticks off our C++ friends. I thought I was going to have >> time to think about this in the next month or two, but I got >> sidetracked on other issues. But I will need to get back to it after >> our WWDC (in June). > > Yes. Rather than focusing on it with a special hack here, I'd rather > eventually address it properly. Thanks for pointing this out. That seems fine. > >> I thought from some comments in other notes that this was something >> you >> were thinking about as well, Daniel. Is that true? > > I'm interested in the problem, but like everyone I have a dreadful > shortage of time :( > Another complication we should address is that gdb currently tries to reset all breakpoints in all shared libraries when it does breakpoint_re_set_all... It would be better if gdb could figure out which shared libraries have been added on a shlib event, and only reset in them. This seems trivial, but on Mac OS X (and I bet on a fully loaded KDE or Gnome system) there are LOTS of shared libraries, and this is a major speed problem. It is even worse for systems with shared library based plugins, where you can end up loading ~100 plugins one by one. Setting ~20 or 30 breakpoints for all the shlibs in the system plus the increasing list from the plugins, for each load of 100 plugins, really dogs down... I think I know how to do this on our gdb, but it will take some more thought to figure out how to do it generically... Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer