On Thu, Aug 3, 2017 at 10:02 AM, Olivier Hainque <hain...@adacore.com> wrote: > Hello, > > Activating dwarf2 based eh for real on VxWorks6 (patch to come) triggers a > libgcc build failure, where most functions resorting to __builtin_eh_return > fail this check from maybe_record_trace_start in dwarf2cfi.c: > > /* We ought to have the same state incoming to a given trace no > matter how we arrive at the trace. Anything else means we've > got some kind of optimization error. */ > #if CHECKING_P > if (!cfi_row_equal_p (cur_row, ti->beg_row)) > ... > > The inconsistency is introduced by a store inserted in the middle of the insn > stream by arm_set_return_address for __builtin_eh_return, marked FRAME_RELATED > with: > > /* The store needs to be marked as frame related in order to prevent > DSE from deleting it as dead if it is based on fp. */ > rtx insn = emit_move_insn (gen_frame_mem (Pmode, addr), source); > RTX_FRAME_RELATED_P (insn) = 1; > add_reg_note (insn, REG_CFA_RESTORE, gen_rtx_REG (Pmode, LR_REGNUM)); > > The FRAME_RELATED ness was setup to fixed DWARF2 unwinding at > the time already, indeed broken by DSE removing the store - see > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01669.html. > > The attached patch is a proposal to fix this by setting MEM_VOLATILE_P on > the store destination mem instead of setting RTX_FRAME_RELATED_P on the insn, > which alleviates the .cfi complications and is as effective in preventing > the store removal by DSE, from: > > /* Assuming that there are sets in these insns, we cannot delete > them. */ > if ((GET_CODE (PATTERN (insn)) == CLOBBER) > || volatile_refs_p (PATTERN (insn)) > || (!cfun->can_delete_dead_exceptions && !insn_nothrow_p (insn)) > || (RTX_FRAME_RELATED_P (insn)) > || find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX)) > insn_info->cannot_delete = true; > > For testing, I verified that > > - an arm-wrs-vxworks build with the extra patch to activate DWARF2 > eh proceeds to completion on mainline, > > - the same symptoms were visible and cured on our in-house > gcc-7 based toolchain, and that > > - ACATS are clean for Ada in this configuration after the patch, > confirming proper behavior of the DWARF2 exception propagation > circuitry. > > OK to commit ? >
This is OK . Sorry about the delay - I've been traveling a bit. Thanks Ramana > Thanks much in advance for your feedback, > > With Kind Regards, > > Olivier >
