Re: SIGSEGV on gdb 6.7*

[Greg Law <glaw@undo-software.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