From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15697 invoked by alias); 4 Sep 2004 19:07:46 -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 15686 invoked from network); 4 Sep 2004 19:07:43 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 4 Sep 2004 19:07:43 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 7026D47D92; Sat, 4 Sep 2004 12:07:42 -0700 (PDT) Date: Sat, 04 Sep 2004 19:07:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: your turn :-) Message-ID: <20040904190742.GW1216@gnat.com> References: <41390838.4050609@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41390838.4050609@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00079.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); + restart: - 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? 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. ??? > 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 > > - 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 Hafta run. -- Joel