From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1069 invoked by alias); 4 Feb 2008 21:39:20 -0000 Received: (qmail 1061 invoked by uid 22791); 4 Feb 2008 21:39:20 -0000 X-Spam-Check-By: sourceware.org Received: from ranger.systems.pipex.net (HELO ranger.systems.pipex.net) (62.241.162.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Feb 2008 21:38:39 +0000 Received: from [192.168.123.6] (88-106-248-241.dynamic.dsl.as9105.com [88.106.248.241]) by ranger.systems.pipex.net (Postfix) with ESMTP id 7C848E000573 for ; Mon, 4 Feb 2008 21:38:36 +0000 (GMT) Message-ID: <47A785DB.7010108@undo-software.com> Date: Mon, 04 Feb 2008 21:39:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: SIGSEGV on gdb 6.7* References: <47A77A6C.8050007@undo-software.com> <20080204210333.GA23250@caradoc.them.org> In-Reply-To: <20080204210333.GA23250@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00088.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Feb 04, 2008 at 08:49:48PM +0000, Greg Law wrote: >> yet there appear to be pointers to the regcache squirrelled away in >> various other places, notably the prologue_cache member of the >> frame_info structure. > > Could you give a specific example? I don't think there should be such > pointers. When a register is examined, we (eventually) get to frame_register_unwind. This does: frame->unwind->prev_register (frame->next, &frame->prologue_cache, regnum, optimizedp, lvalp, addrp, realnump, bufferp); which is actually a function pointer to (on plain old x86 Linux) sentinel_frame_prev_register, which goes: static void sentinel_frame_prev_register (struct frame_info *next_frame, void **this_prologue_cache, int regnum, int *optimized, enum lval_type *lvalp, CORE_ADDR *addrp, int *realnum, gdb_byte *bufferp) { struct frame_unwind_cache *cache = *this_prologue_cache; /* Describe the register's location. A reg-frame maps all registers onto the corresponding hardware register. */ *optimized = 0; *lvalp = lval_register; *addrp = register_offset_hack (current_gdbarch, regnum); *realnum = regnum; /* If needed, find and return the value of the register. */ if (bufferp != NULL) { /* Return the actual value. */ /* Use the regcache_cooked_read() method so that it, on the fly, constructs either a raw or pseudo register from the raw register cache. */ regcache_cooked_read (cache->regcache, regnum, bufferp); } } note the first line which is an assignment to 'cache' from *this_prologue_cache. The regcache_cooked_read is called, passing cache->regcache. If flushregs has been called, the regcache appears to be garbage. If I've not got myself terribly confused, this is not especially surprising, since we freed the regcache at registers_changed(), leaving the frame_info structure pointing at invalid memory. > >> I guess this might result in some "unnecessary" fetches of the register >> state, but that has to be favourable to a SEGV :) > > Not really - we go to a lot of trouble to avoid this. Yeah, I guess this more important on remote targets over slow links, right? In that case, do we not need to take care from registers_changed() to go and invalidate all the pointers to cached registers in the frame structures? Hmm, although thinking about it now, I guess the frame structures all need throwing away/recalculating if the registers have changed anyway? I can't find what causes that to happen though. g