From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19793 invoked by alias); 4 Sep 2004 23:58:12 -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 19782 invoked from network); 4 Sep 2004 23:58:10 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Sep 2004 23:58:10 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i84NwAS2006241 for ; Sat, 4 Sep 2004 19:58:10 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i84Nw8325514; Sat, 4 Sep 2004 19:58:09 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AE52328D2; Sat, 4 Sep 2004 19:56:57 -0400 (EDT) Message-ID: <413A5649.8070205@gnu.org> Date: Sat, 04 Sep 2004 23:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: your turn :-) References: <41390838.4050609@gnu.org> <20040904190742.GW1216@gnat.com> In-Reply-To: <20040904190742.GW1216@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00085.txt.bz2 > I'll see if I can take care of this. Right now, GDB is completely > broken again. This change sort of patch things up a little bit > by preventing a SEGV. But we get some other problems that just > screw the testsuite run. > > > Index: mips-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/mips-tdep.c,v > retrieving revision 1.320 > diff -u -p -r1.320 mips-tdep.c > --- mips-tdep.c 4 Sep 2004 00:16:56 -0000 1.320 > +++ mips-tdep.c 4 Sep 2004 18:59:18 -0000 > @@ -2762,9 +2762,17 @@ mips32_heuristic_proc_desc (CORE_ADDR st > { > CORE_ADDR cur_pc; > CORE_ADDR frame_addr = 0; /* Value of $r30. Used by gcc for frame-pointer */ > + > + /* FIXME: brobecker/2004-09-04: We're in the middle of a transition, > + and this_cache may be NULL. In that case, then create a new one > + just for now. It means a memory leak, but oh well, I don't care. */ > + if (this_cache == NULL) > + this_cache = FRAME_OBSTACK_ZALLOC (struct mips_frame_cache); This shouldn't be needed, hmm: > restart: oops, this should be deleted. An earlier change modified set_reg_offset to ignore NULL pointers. > - this_cache = xrealloc (this_cache, SIZEOF_FRAME_SAVED_REGS); > - memset (this_cache, '\0', SIZEOF_FRAME_SAVED_REGS); > + this_cache->saved_regs = xrealloc (this_cache->saved_regs, > + SIZEOF_FRAME_SAVED_REGS); > + memset (this_cache->saved_regs, '\0', SIZEOF_FRAME_SAVED_REGS); > PROC_FRAME_OFFSET (&temp_proc_desc) = 0; > PROC_FRAME_ADJUST (&temp_proc_desc) = 0; /* offset of FP from SP */ > for (cur_pc = start_pc; cur_pc < limit_pc; cur_pc += MIPS_INSTLEN) > > I guess you really don't want to see me incorporate my last RFA > until the cleanup is done, eh? > > > On Fri, Sep 03, 2004 at 08:11:36PM -0400, Andrew Cagney wrote: > >>> Joel >>> >>> The theory is to enable this: >>> >>> #ifdef NOT_YET >>> proc_desc = heuristic_proc_desc (start_addr, pc, next_frame, >>> this_cache); >>> #else >>> proc_desc = heuristic_proc_desc (start_addr, pc, next_frame, NULL); >>> #endif > > > What should heuristic_proc_desc do if the cache given is NULL. > Create a temporary one while scaning the function, and then > trash it? No, the code should survive a NULL this_cache. > Another question that's troubling me: I can't see how mips_frame_cache > structs are deallocated. I am guessing that this happens when the > obstack is reset, but then that would mean that we leak the save_regs > array. ??? Right. The deallocate occures each time the frame cache is flushed and that occures over and over. >>> Then: >>> >>> - delete the rest of the insn{32,16}_frame_cache code as its redundant, >>> the heuristic code will have already updated the cache >>> >>> - eliminate proc_desc from mips{32,16}_heuristic ... as its redundant, >>> the code only needs to update this_cache This might get changed. I've this hunch that heuristic_proc_desc may need to be changed to return the last instruction - indicating the end of the prologue. But worry about this latter. >>> - either inline mips{32,16}_heuristic into mips_insn{32,16}_frame_cache >>> or, instead, merge mips_insn{32,16}_frame_cache. >>> >>> want to try it (the test results don't even need to vaguely pass). >>> >>> Andrew Andrew