From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10321 invoked by alias); 12 Aug 2003 17:36:22 -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 10314 invoked from network); 12 Aug 2003 17:36:21 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 12 Aug 2003 17:36:21 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A39FA2B7F; Tue, 12 Aug 2003 13:36:17 -0400 (EDT) Message-ID: <3F392591.4050409@redhat.com> Date: Tue, 12 Aug 2003 17:36:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: CRIS port; frame cleanup crash References: <3F379A74.4080508@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00199.txt.bz2 > After a long overdue update of my gdb cvs tree, I found that something broke late March/early April. I don't quite understand what goes on, but it seems to happen the first time a frame allocated by deprecated_frame_xmalloc_with_cleanup is freed by do_cleanups (which happens in cris_skip_prologue_main). gdb segfaults on a call to free with a pointer to that frame. The arm-tdep.c file contains the same construct of: > > old_chain = make_cleanup (null_cleanup, NULL); > frame = deprecated_frame_xmalloc_with_cleanup (..., ...) > > do_cleanups (old_chain); Er, that points at a bug: struct frame_info * deprecated_frame_xmalloc (void) { struct frame_info *frame = FRAME_OBSTACK_ZALLOC (struct frame_info); frame->this_id.p = 1; return frame; } shouldn't be allocated from the frame obstack pool. I'll commit a fix. > However, poking around in all the stuff that has been deprecated, I'm sort of at a loss as to where to start. Replacing the deprecated function/macros one at a time doesn't look feasible, since a lot of functionality is replaced by the same functions (push_dummy_code/push_dummy_call for example). Is there a preferred way of doing it, or is it just a matter of diving right into it? I'd prefer to do it in a structured way to be able to catch when things start to break. I see there are a couple of targets that have made the transition (d10v and m68hc11 for example), so that should provide some help. ia64, Arm, ... Some people are diving straight in, some are atacking the edges - updating any deprecated methods first. Andrew