From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12040 invoked by alias); 26 Feb 2003 15:47:35 -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 12033 invoked from network); 26 Feb 2003 15:47:35 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 26 Feb 2003 15:47:35 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18o5fN-0001dG-00; Wed, 26 Feb 2003 11:48:25 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18o3m6-00031D-00; Wed, 26 Feb 2003 10:47:14 -0500 Date: Wed, 26 Feb 2003 15:47:00 -0000 From: Daniel Jacobowitz To: Michal Ludvig Cc: Elena Zannoni , GDB Patches , Andrew Cagney Subject: Re: PING: [RFA] Runtime Dwarf2 CFI engine cleanup Message-ID: <20030226154714.GA11458@nevyn.them.org> Mail-Followup-To: Michal Ludvig , Elena Zannoni , GDB Patches , Andrew Cagney References: <3E197C8F.3010903@suse.cz> <15934.38824.98344.150611@localhost.redhat.com> <3E479B6A.30705@suse.cz> <3E5CDEB8.2050008@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5CDEB8.2050008@suse.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00705.txt.bz2 On Wed, Feb 26, 2003 at 04:35:20PM +0100, Michal Ludvig wrote: > Michal Ludvig wrote: > >Elena Zannoni wrote: > > > >>Michal Ludvig writes: > >> > Hi all, > >> > the attached is a fix for the problem described here: > >> > http://sources.redhat.com/ml/gdb/2002-12/msg00246.html > >> > > I've created a new function cleanup_cfi() in dwarf2cfi.c that > >>deletes > all CIEs and FDEs of objfiles removed later by > >>objfile_purge_solibs(). > >> > So far it works fine but I don't know how should I correctly call it. > >> > >>I have tried your function, and it does fixes some weird errors which > >>occur > >>on rerun. > >>I just tried by using the hack of defining GDB_TARGET_IS_X86_64, which > >>is definitely a bad thing. > >> > >>I think that the best way is to define a gdbarch method, just like it > >>was done for gdbarch_dwarf2_build_frame_info. > > > > > >How about adding dwarf2cfi.o to all targets? When there is for example > >mipsread.o compiled into gdb on x86-64 (why? because there is no option > >to say what features a given target needs.) than dwarf2cfi.o could go > >there as well... > >I hope more and more targets will use it in the near future. > > > >The attached is a version that adds dwarf2cfi.o for all targets. If it's > >unacceptable this way I'll provide gdbarch-ed version instead. But I > >think that gdbarch_*() functions are good for the case when on different > >targets a different functions are called to do a given task (eg. read > >register). But in this case you must call cleanup_cfi() in all targets > >that use CFI. No option. Calling it shouldn't depend on setting gdbarch > >value. Instead it should depend on linking dwarf2cfi.o into the gdb. > > > >>In the patch below, you cannot use printf's. Use printf_filtered. But > >>maybe, better yet, using a warning here would be more appropriate. > > > > > >It isn't a warning, just an informational message. Now it's printed only > >when info_verbose is set. > > > >>Watch out for the non-GNU indentation and spacing. > > > > > >Reindented. > > > >OK to commit? > > > >Michal Ludvig > > Could someone *please* comment on this two months old patch? > Can I at least commit the dwarf2cfi.c part (proven to be stable since > it's in use in our GDB package), so that it could eventually be > triggered by adding one single line to infcmd.c? > Without this patch the CFI engine is very unstable. Is there a reason > why not to commit it? > > Ad triggering cleanup_cfi() - there are several possibilities: > 1) Add dwarf2cfi.o to all targets in Makefile.in and call cleanup_cfi() > from run_command() w/o obstructions. > 2) To all targets that use CFI add macro USE_DWARF2CFI to their > config/what/ever.h and wrap call to cleanup_cfi() by appropriate ifdefs. > 3) Create gdbarch_whatever(_p) to call it. I don't think it's a good > idea - there is no point in setting this macro to something else or > unsetting it. > [in order of preference] > > I would really like to get rid of this pending patch from my todo list. > > Thanks in advance 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. 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.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer