This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] Frame based register cache / frame->unwind
> On Apr 14, 4:58pm, Andrew Cagney wrote:
>> I'm not too worried about the apparent 2% overhead per frame create
>> though. With the patch applied, the code ends up maintaining both this
>> new cache and the old ->saved_regs table. Rewriting a target to just
>> use the ->unwind_cache, should, I think, claw back the 2% and then some
>> - less need to go out to the target.
> I'm puzzled. Assuming you don't have dwarf2cfi or the like, how do you
> avoid maintaining the old ->saved_regs table?
Old code would have ->saved_registers. Newer code could pre-load the
cache instead of ->saved_registers.
The case I considered here was SP where ->saved_registers contains the
value and not the address. Added the function
frame_supply_unwound_register() with that in mind.
The others are ``addresses'' though. The cache would need tinkering for
this to work - capable of recording the ``address'' and/or the value.
The frame_supply_unwound_register() (unused) was a step in that direction.
> Hmm... I see that the unwind cache has an ``addr'' field. Does that
> mean that that the prologue analysis function calls
> frame_supply_unwound_register() to set this field?
Yes, that is what I had in mind. But see above, it needs tinkering.
> What is the ``optimized'' flag (in the frame cache) used for?
Grep for OPTIMIZED, it is used but it probably isn't applicable to
registers. I just cache everything :-)
There should probably be an ``unavailable'' indication instead, I'm not
trying to change that part of the code though. (There is a
register_valid() call that isn't reliable.)