Add constructor DWARF calling convention for every supported LLVM CC

[aguinet]

Summary

This is also associated with a clang commit that uses them to emit every supported clang/llvm CC in dwarf informations!

GCC's private calling conventions are also added.

[rnk]

I'm in favor of doing this. Any concerns, @aprantl? AAPCS is the only one I can think of that's so common this might upset some DWARF consumer.

[aprantl]

I suppose the namespace for DW_CCs is large enough that doing this isn't very risky. Have you double-checked that this doesn't overlap with any other vendor extensions?

[aguinet]

In D42350#983933, @aprantl wrote:

I suppose the namespace for DW_CCs is large enough that doing this isn't very risky. Have you double-checked that this doesn't overlap with any other vendor extensions?

Actually I didn't. I'm gonna try and find this for at least gcc and icc! I'll let you know.

[aprantl]

By the way, if you can contribute patches that add more 3rd party DWARF extensions to LLVM, that would be awesome to help avoiding clashes in the future.

[aguinet]

In D42350#983998, @aprantl wrote:

By the way, if you can contribute patches that add more 3rd party DWARF extensions to LLVM, that would be awesome to help avoiding clashes in the future.

I've added the private ones of GCC according to this: https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.h#L182 .

I'll try to do the same with icc by tring the various ABI it supports (https://software.intel.com/en-us/node/522787), and getting the potential value with readelf (all with a script to be able to run this again!)

[aguinet]

I'll try to do the same with icc by tring the various ABI it supports (https://software.intel.com/en-us/node/522787), and getting the potential value with readelf (all with a script to be able to run this again!)

Per this script https://pastebin.com/pDwJfRyt, it seems that ICC never emits DWARF calling convention attributes. One thing that seems weird thought is that they don't support the CC they say they suuport on the link I gave.

If someone with ICC could also try this please to see if I don't miss something.. !

[JDevlieghere]

In D42350#994457, @aguinet wrote:

I'll try to do the same with icc by tring the various ABI it supports (https://software.intel.com/en-us/node/522787), and getting the potential value with readelf (all with a script to be able to run this again!)

Per this script https://pastebin.com/pDwJfRyt, it seems that ICC never emits DWARF calling convention attributes. One thing that seems weird thought is that they don't support the CC they say they suuport on the link I gave.

If someone with ICC could also try this please to see if I don't miss something.. !]

Hi @mibintc; would you mind confirming that ICC doesn't emit DWARF CC attributes or (if it does) that they don't overlap with the ones in this diff?

[mibintc]

Hi @mibintc; would you mind confirming that ICC doesn't emit DWARF CC attributes or (if it does) that they don't overlap with the ones in this diff?

Sure i don't mind checking. While icc does support the calling conventions, the compiler is not emitting the dwarf calling convention attributes.

[JDevlieghere]

In D42350#1044486, @mibintc wrote:

Hi @mibintc; would you mind confirming that ICC doesn't emit DWARF CC attributes or (if it does) that they don't overlap with the ones in this diff?

Sure i don't mind checking. While icc does support the calling conventions, the compiler is not emitting the dwarf calling convention attributes.

Thanks!

This LGTM then.

[aguinet]

Thanks everyone for the review and comments!

[aguinet]

BTW, I don't have any commit rights thought, so I guess someone needs to merge this at some point?

https://reviews.llvm.org/D42351 is in the same status!

include/llvm/BinaryFormat/Dwarf.def

 // DWARF calling convention codes.
 HANDLE_DW_CC(0x01, normal)
 HANDLE_DW_CC(0x02, program)
 HANDLE_DW_CC(0x03, nocall)
 // New in DWARF v5:
 HANDLE_DW_CC(0x04, pass_by_reference)
 HANDLE_DW_CC(0x05, pass_by_value)
 // Vendor extensions:
+HANDLE_DW_CC(0x40, GNU_renesas_sh)
 HANDLE_DW_CC(0x41, GNU_borland_fastcall_i386)
 HANDLE_DW_CC(0xb0, BORLAND_safecall)
 HANDLE_DW_CC(0xb1, BORLAND_stdcall)
 HANDLE_DW_CC(0xb2, BORLAND_pascal)
 HANDLE_DW_CC(0xb3, BORLAND_msfastcall)
 HANDLE_DW_CC(0xb4, BORLAND_msreturn)
 HANDLE_DW_CC(0xb5, BORLAND_thiscall)
 HANDLE_DW_CC(0xb6, BORLAND_fastcall)
 HANDLE_DW_CC(0xc0, LLVM_vectorcall)
+HANDLE_DW_CC(0xc1, LLVM_Win64)
+HANDLE_DW_CC(0xc2, LLVM_X86_64SysV)
+HANDLE_DW_CC(0xc3, LLVM_AAPCS)
+HANDLE_DW_CC(0xc4, LLVM_AAPCS_VFP)
+HANDLE_DW_CC(0xc5, LLVM_IntelOclBicc)
+HANDLE_DW_CC(0xc6, LLVM_SpirFunction)
+HANDLE_DW_CC(0xc7, LLVM_OpenCLKernel)
+HANDLE_DW_CC(0xc8, LLVM_Swift)
+HANDLE_DW_CC(0xc9, LLVM_PreserveMost)
+HANDLE_DW_CC(0xca, LLVM_PreserveAll)
+HANDLE_DW_CC(0xcb, LLVM_X86RegCall)
+// From GCC source code (include/dwarf2.h): This DW_CC_ value is not currently
+// generated by any toolchain.  It is used internally to GDB to indicate OpenCL C
+// functions that have been compiled with the IBM XL C for OpenCL compiler and use
+// a non-platform calling convention for passing OpenCL C vector types.
+HANDLE_DW_CC(0xff, GDB_IBM_OpenCL)
 
 // Line Number Extended Opcode Encodings
 HANDLE_DW_LNE(0x01, end_sequence)
 HANDLE_DW_LNE(0x02, set_address)
 HANDLE_DW_LNE(0x03, define_file)
 // New in DWARF v4:
 HANDLE_DW_LNE(0x04, set_discriminator)