From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25211 invoked by alias); 26 Feb 2003 18:36:03 -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 25204 invoked from network); 26 Feb 2003 18:36:03 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 26 Feb 2003 18:36:03 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18o8Id-0001wT-00; Wed, 26 Feb 2003 14:37:07 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18o6PM-0004He-00; Wed, 26 Feb 2003 13:35:56 -0500 Date: Wed, 26 Feb 2003 18:36:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , Elena Zannoni , GDB Patches Subject: Re: PING: [RFA] Runtime Dwarf2 CFI engine cleanup Message-ID: <20030226183555.GA16345@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michal Ludvig , Elena Zannoni , GDB Patches References: <3E197C8F.3010903@suse.cz> <15934.38824.98344.150611@localhost.redhat.com> <3E479B6A.30705@suse.cz> <3E5CDEB8.2050008@suse.cz> <20030226154714.GA11458@nevyn.them.org> <3E5D05F9.6050605@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5D05F9.6050605@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00723.txt.bz2 On Wed, Feb 26, 2003 at 01:22:49PM -0500, Andrew Cagney wrote: > > > > > >I don't think that the way you're selecting objfiles to unload is ideal > >- you're duplicating logic from objfile_purge_solibs. We need a more > >general hook to free objfile-specific information. However, I believe > >that can be addressed separately, and this will definitely fix some > >crashes as-is and not introduce any new ones. > > > >I don't have any problem with linking dwarf2cfi.o in for all targets. > >Let's sit on this for another day and see if anyone else objects, and > >then you can commit it. > > A quick look at the bigger picture reveals: > > - the underlying code needs to be fixed before it is linked into all > targets. Why? The code can be fixed as it is activated for other targets; linking and use aren't the same thing. I'd even call this the first step in fixing it - doesn't break anything and makes it easier for other targets to test it. > - if it needs to be modified of changes in another part of gdb then it > should use an observer. It should not introduce another hack. > > You'll note that Joel and I are currently working through this. Yes it > means that the posted patch doesn't go in. It also means that GDB is > that bit more (not less) maintainable. OK, if that's your preference, Michal please do not check in this patch. I think it's a bit silly to reject a patch which fixes a "break; run; run" segfault on this basis, especially one two months or more old, though. This is one of the two major issues I know about that are forcing Michal to do x86-64 development on 5.3 instead of HEAD. I applaud your vision in preserving future maintainability; I'm tired of that vision interfering with having a working GDB. > >You made a line in Makefile.in too wide; please fix that before you > >check it in. > > > >[List: my assumption in approving this is that the dwarf2cfi support is > >not part of the dwarf2 reader, so I'm not stepping on anyone's toes. > >If you disagree, please tell me so.] > > Puzzled expression. This is the problem with vague lines of authority. It's not always clear who can approve a patch even to people who do the approving. I'm tired of exercising what seems to be pretty clear authority to approve something and getting prickly mail from someone else overturning my decision. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer