Re: SIGSEGV on gdb 6.7*

[Greg Law <glaw at undo-software dot com>]

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