[2/5][DWARF] Generate dwarf information for -msign-return-address by introducing new DWARF mapping hook

[Jiong Wang]

On 13/01/17 18:02, Jiong Wang wrote:
> On 13/01/17 16:09, Richard Earnshaw (lists) wrote:
>> On 06/01/17 11:47, Jiong Wang wrote:
>>>
>>> This patch is an update on DWARF generation for return address signing.
>>>
>>> According to new proposal, we simply needs to generate 
>>> REG_CFA_WINDOW_SAVE
>>> annotation.
>>>
>>> gcc/
>>>
>>> 2017-01-06  Jiong Wang  <jiong.wang@arm.com>
>>>
>>>          * config/aarch64/aarch64.c (aarch64_expand_prologue): Generate
>>> dwarf
>>>          annotation (REG_CFA_WINDOW_SAVE) for return address signing.
>>>          (aarch64_expand_epilogue): Likewise.
>>>
>>>
>> I don't think we should be overloading REG_CFA_WINDOW_SAVE internally in
>> the compiler -- it's one thing to do it in the dwarf output tables, but
>> quite another to be doing it elsewhere in the compiler.
>>
>> Instead we should create a new reg note kind and use that, but in the
>> final dwarf output then emit the overloaded opcode.
>
> I can see the reason for doing this is if you want to seperate the 
> interpretion
> of GCC CFA reg-note and the final DWARF CFA operation.  My 
> understanding is all
> reg notes defined in gcc/reg-note.def should have general meaning, 
> even the
> CFA_WINDOW_SAVE.  For those which are architecture specific we might 
> need a
> mechanism to define them in backend only.
>    For general reg-notes in gcc/reg-note.def, they are not always have 
> the
> corresponding standard DWARF CFA operation, for example CFA_WINDOW_SAVE,
> therefore if we want to achieve what you described, I think we also 
> need to
> define a new target hook which maps a GCC CFA reg-note into 
> architecture DWARF
> CFA operation.
>
> Regards,
> Jiong
>
>
Here is the patch.

Introduced one new target hook TARGET_DWARF_MAP_REGNOTE_TO_CFA.  The purpose is
to allow GCC to map DWARF CFA reg notes in reg-note.def, which looks to me have
generic meaning, into target private DWARF CFI if there is no standard DWARF CFI
mapping.

One new GCC reg-note REG_TOGGLE_RA_MANGLE introduced as well, currently, it's
only used by AArch64 to implement return address signing and is mapped to
AArch64's target private DWARF CFI.

Does this approach and implementation looks OK?

I can come up with seperate patches to define this hook on Sparc for
CFA_WINDOW_SAVE, and to remove redundant including of dwarf2.h although there is
"ifdef" protector in header file.

The default hook implementation "default_dwarf_map_regnote_to_cfa" in
targhooks.c used the types "enum reg_note" and "enum dwarf_call_frame_info"
which is not included in coretypes.h thus this patch has several change in
header files.  I have done X86 bootstrap to make sure no build breakage.  I'd
appreciate there is better ideas to handle these type define.

Thanks.

gcc/ChangeLog:

2017-01-16  Jiong Wang  <jiong.wang@arm.com>

         * target.def (dwarf_map_regnote_to_cfa): New hook.
         * targhooks.c (default_dwarf_map_regnote_to_cfa): Default implementation
         for TARGET_DWARF_MAP_REGNOTE_TO_CFA.
         * targhooks.h (default_dwarf_map_regnote_to_cfa): New declaration.
         * rtl.h (enum reg_note): Move enum reg_note to...
         * coretypes.h: ... here.
         (dwarf2.h): New include file.
         * reg-notes.def (CFA_TOGGLE_RA_MANGLE): New reg-note.
         * combine-stack-adj.c (no_unhandled_cfa): Handle
         REG_CFA_TOGGLE_RA_MANGLE.
         * dwarf2cfi.c (dwarf2out_frame_debug_cfa_toggle_ra_mangle): New
         function.
         (dwarf2out_frame_debug): Handle REG_CFA_TOGGLE_RA_MANGLE.
         * doc/tm.texi: Regenerate.
         * doc/tm.texi.in: Documents TARGET_DWARF_MAP_REGNOTE_TO_CFA.
         * config/aarch64/aarch64.c (aarch64_map_regnote_to_cfa): Implements
         TARGET_DWARF_MAP_REGNOTE_TO_CFA.
         (aarch64_expand_prologue): Generate DWARF info for return address
         signing.
         (aarch64_expand_epilogue): Likewise.
         (TARGET_DWARF_MAP_REGNOTE_TO_CFA): Define.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 8520 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20170116/68448551/attachment.bin>