| Message ID | 543D1EEE.5070903@st.com |
|---|---|
| State | New |
| Headers | show |
On 10/14/2014 06:02 AM, Christian Bruel wrote: > 2014-09-23 Christian Bruel <christian.bruel@st.com> > > * execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each function. It's tempting to make this a local variable within dwarf2out_frame_debug_expr and not try to cache it at all. But this is ok. r~
On 10/14/2014 11:25 AM, Richard Henderson wrote: > On 10/14/2014 06:02 AM, Christian Bruel wrote: >> 2014-09-23 Christian Bruel <christian.bruel@st.com> >> >> * execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each function. > > It's tempting to make this a local variable within dwarf2out_frame_debug_expr > and not try to cache it at all. > > But this is ok. For the record, this also points out that the arm backend ought to be weaned away from using dwarf2out_frame_debug_expr and use the REG_CFA_* notes exclusively. That would also fix an apparent error in arm_expand_prologue: if (IS_INTERRUPT (func_type)) { /* Interrupt functions must not corrupt any registers. Creating a frame pointer however, corrupts the IP register, so we must push it first. */ emit_multi_reg_push (1 << IP_REGNUM, 1 << IP_REGNUM); /* Do not set RTX_FRAME_RELATED_P on this insn. The dwarf stack unwinding code only wants to see one stack decrement per function, and this is not it. If this instruction is labeled as being part of the frame creation sequence then dwarf2out_frame_debug_expr will die when it encounters the assignment of IP to FP later on, since the use of SP here establishes SP as the CFA register and not IP. Anyway this instruction is not really part of the stack frame creation although it is part of the prologue. */ Certainly dwarf2cfi can handle arbitrary REG_CFA_ADJUST_CFA notes; it's just the frame_debug_expr state machine that gets confused. r~
committed, thanks sorry for the delay. Christian On 10/14/2014 08:25 PM, Richard Henderson wrote: > On 10/14/2014 06:02 AM, Christian Bruel wrote: >> 2014-09-23 Christian Bruel <christian.bruel@st.com> >> >> * execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each function. > > It's tempting to make this a local variable within dwarf2out_frame_debug_expr > and not try to cache it at all. > > But this is ok. > > > r~ >
2014-09-23 Christian Bruel <christian.bruel@st.com> * execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each function. Index: dwarf2cfi.c =================================================================== --- dwarf2cfi.c (revision 216146) +++ dwarf2cfi.c (working copy) @@ -2860,7 +2860,6 @@ dw_trace_info cie_trace; dw_stack_pointer_regnum = DWARF_FRAME_REGNUM (STACK_POINTER_REGNUM); - dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM); memset (&cie_trace, 0, sizeof (cie_trace)); cur_trace = &cie_trace; @@ -2913,6 +2912,9 @@ static unsigned int execute_dwarf2_frame (void) { + /* Different HARD_FRAME_POINTER_REGNUM might coexist in the same file. */ + dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM); + /* The first time we're called, compute the incoming frame state. */ if (cie_cfi_vec == NULL) create_cie_data ();
Hello, ARM and Thumb modes use different hard_frame_pointer_regnum ABIs. The problem is that dwarf2cfi.c:dw_frame_pointer_regnum cache is initialized only once per file, when creating the CIE. While testing the ARM attribute target to switch modes between functions, I got a few assertion with -g, because this value gets inconsistent with the respective FDEs that have different hard_frame_pointer_rtx... The snippet from dwarf2cfi.c illustrates the potential issue with the mismatch between hard_frame_pointer_rtx and a badly set CFA register : if (dest == hard_frame_pointer_rtx) ... cur_cfa->reg = dw_frame_pointer_regnum; ... I'm not aware of other targets giving the possibility to change the frame_pointer_regnum ABI in a file, so the issue will only be show up with the ARM target attribute. However I'd like very much your feedback on this change, before I can send the remaining ARM parts. Tested manually for arm-none-eabi with gdb, unwinding and frame access seem OK when mixing modes. x86 bootstrapped and regressions tests are running. Many thanks, Christian