This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [CRIS] dwarf2 frame sniffer problem?


Orjan Friberg wrote:
Daniel Jacobowitz wrote:


The beauty of using the CFI data is that it _is_ supposed to work in the prologue. It sounds like the CFI is wrong. Could you post both assembly and CFI data for the same testcase? I don't know CRIS assembly but I imagine I can interpret it well enough to see what's going on.

Out of curiosity, I had a look at the calls to execute_cfa_program (where the current state of the registers seems to be built from the dwarf2 information). The second call to execute_cfa_program is preceded by the comment:


/* Then decode the insns in the FDE up to our target PC. */

When we get into execute_cfa_program we're stopped at the first instruction in foo, and the pc variable in execute_cfa_program is set to that value also. Nevertheless we parse *all* the information in that FDE:

00000028 00000014 00000000 FDE cie=00000000 pc=00080080..00080096
  DW_CFA_advance_loc: 0 to 00080080
  DW_CFA_def_cfa: r8 ofs 8
  DW_CFA_offset: r16 at cfa-4
  DW_CFA_offset: r8 at cfa-8

So, not only do we incorrectly conclude that the SRP is located on the stack, but that the frame pointer (r8) is also (though neither of those have actually been pushed yet). Comparing with the example in Appendix 5 of the dwarf2 spec I get the impression that some DW_CFA_advance_loc are missing, but now is probably a good time for me to stop guessing ;-) .


--
Orjan Friberg
Axis Communications


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