This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

think-o: dwarf2 CFA != frame->frame (x86-64)


The x86-64 port, being the first to try to use dwarf2 cfa, is in the fun 
position of having to figure out how to integrate some of this stuff 
into gdb.  Just noticed this one...

x86-64 sets the function read_fp() to:

   set_gdbarch_read_fp (gdbarch, cfi_read_fp);

And the corresponding code:

/* Return the frame address.  */
cfi_read_fp ()
   struct context *context;
   struct frame_state *fs;
   CORE_ADDR cfa;

   context = context_alloc ();
   fs = frame_state_alloc ();

   context->ra = read_pc () + 1;

   frame_state_for (context, fs);
   update_context (context, fs, 0);

   cfa = context->cfa;
   unwind_tmp_obstack_free ();
   return cfa;

Going through the dwarf2++ spec, I've seen CFA (Call Frame Address) and 
frame_base.  While they might turn out to have the same value, they are, 
I think, very different.

The CFA is a CFI specific concept (all about how to unwind stack frames 
and find register values) that, as far as I can tell, isn't intended for 
``public consumption''.  It is used by the stack unwind code as a base 
address for the frame being unwound.  As far as

Separate to this is the frame_base attribute of a function. My 
interpretation of this attribute is that it defines the traditional 
``frame pointer''.

I don't think x86-64-tdep.c should be using the CFA for frame->frame. 
Instead it should be computing frame_base.,

I'll likely bug-report this.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]