[PATCH] [DWARF] Kotlin language

[vvlevchenko]

Summary

Patch adds a DWARF language tag for Kotlin.
The language is intended to be added to the next version of the standard.
See http://www.dwarfstd.org/ShowIssue.php?issue=170503.1
For a moment language tag is placed in LLVM language extensions region.

[aprantl]

Please be warned that until the constant made it into an actual DWARF specification the numerical value could still change so you probably should be careful about shipping software depending on this value to end-users.

include/llvm/BinaryFormat/Dwarf.def

670

I think this should be "6", not "5"?

[aprantl]

It would be nice to also add a testcase that compiles an otherwise empty llvm IR file with a DICompileUnit with Kotlin as the implementation language and pipes the output to llvm-dwarfdump and verifies that it comes out correctly.

include/llvm/BinaryFormat/Dwarf.def

670

Could you please also add a
// Tentative DWARF v.6 definitions.
comment above to drive home the point that these are subject to change?

thanks!

[JDevlieghere]

LGTM with Adrian's comment addressed.

include/llvm/BinaryFormat/Dwarf.def

670

I think Adrian meant DWARF v6 without the dot as we currently stylize DWARF v5.

[probinson]

It would be safer if we came up with an LLVM extension range for language constants (assuming the DWARF committee doesn't change the process for assigning language constants). It will be years before DWARF v6 comes out and there is a very reasonable chance that the numbers won't match.
I'd rather we don't ship any LLVM that could emit an incorrect language code.

[probinson]

+echristo re defining an LLVM range of language codes.

[vvlevchenko]

In D47811#1269475, @probinson wrote:

It would be safer if we came up with an LLVM extension range for language constants (assuming the DWARF committee doesn't change the process for assigning language constants). It will be years before DWARF v6 comes out and there is a very reasonable chance that the numbers won't match.
I'd rather we don't ship any LLVM that could emit an incorrect language code.

Just for my understanding. You suggest to put Kotlin under vendor extension? with id in range DW_LANG_lo_user ... DW_LANG_hi_user. If so who will choose the number? and what supposed to be the last two parameters HANDLE_DW_LANG(..., Kotlin, ) in this case?

[aprantl]

Here's an incomplete list of extensions that haven't all been added to LLVM yet: https://sourceware.org/elfutils/DwarfExtensions

[aprantl]

patches welcome, btw. :-)

[vvlevchenko]

In D47811#1272581, @aprantl wrote:

Here's an incomplete list of extensions that haven't all been added to LLVM yet: https://sourceware.org/elfutils/DwarfExtensions

Hm..., now I'm even more confused :)
If there's any list of actions should be done to land this or appropriate change? I'd very appreciate any suggestion or clarification.

[aprantl]

I think a patch that adds the missing constants to Dwarf.def would be sufficient. This is mostly for documentation purposes to avoid accidentally re-use ranges used by other compilers.

It's possible that libdwarf (http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump) also defines additional extensions.

[vvlevchenko]

In D47811#1272883, @aprantl wrote:

I think a patch that adds the missing constants to Dwarf.def would be sufficient. This is mostly for documentation purposes to avoid accidentally re-use ranges used by other compilers.

Could you please elaborate more? I still doesn't understand which constants are missed and how I can get them. Actually I have got only one assigned by dwarfstd http://www.dwarfstd.org/ShowIssue.php?issue=170503.1.

It's possible that libdwarf (http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump) also defines additional extensions.

[aprantl]

In D47811#1272985, @vvlevchenko wrote:

In D47811#1272883, @aprantl wrote:

I think a patch that adds the missing constants to Dwarf.def would be sufficient. This is mostly for documentation purposes to avoid accidentally re-use ranges used by other compilers.

Could you please elaborate more? I still doesn't understand which constants are missed and how I can get them. Actually I have got only one assigned by dwarfstd http://www.dwarfstd.org/ShowIssue.php?issue=170503.1.

It's possible that libdwarf (http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump) also defines additional extensions.

Note that is is only tangentially related to your patch.

Paul was asking that instead of using the tentative DWARF 6 definition, you'd allocate an LLVM vendor extension somewhere between DW_LANG_lo_user and DW_LANG_hi_user. From there we discussed how to make a safe choice, which prompted me to point out that the list of vendor extensions in LLVM isn't complete and that there are a couple of other sources to consult before picking a spare number. And I said it would be nice (but not necessary!) to submit a patch that adds other known vendor extensions to LLVM's Dwarf.def so this gets easier next time.

[vvlevchenko]

In D47811#1273040, @aprantl wrote:

In D47811#1272985, @vvlevchenko wrote:

In D47811#1272883, @aprantl wrote:

I think a patch that adds the missing constants to Dwarf.def would be sufficient. This is mostly for documentation purposes to avoid accidentally re-use ranges used by other compilers.

Could you please elaborate more? I still doesn't understand which constants are missed and how I can get them. Actually I have got only one assigned by dwarfstd http://www.dwarfstd.org/ShowIssue.php?issue=170503.1.

It's possible that libdwarf (http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump) also defines additional extensions.

Note that is is only tangentially related to your patch.

Paul was asking that instead of using the tentative DWARF 6 definition, you'd allocate an LLVM vendor extension somewhere between DW_LANG_lo_user and DW_LANG_hi_user. From there we discussed how to make a safe choice, which prompted me to point out that the list of vendor extensions in LLVM isn't complete and that there are a couple of other sources to consult before picking a spare number. And I said it would be nice (but not necessary!) to submit a patch that adds other known vendor extensions to LLVM's Dwarf.def so this gets easier next time.

Thank you, for clarification.

[probinson]

I've put a note out to the DWARF committee to see if we can streamline the assignment of language codes. As long as there is a source of truth for these, we shouldn't have to wait for DWARF 6 to be published.
The idea has come up before, and now with a motivating case I think it's likely to happen. So if you could hold off a little longer (probably a few days) I can have an answer for you on that point.

[vvlevchenko]

In D47811#1273052, @probinson wrote:

I've put a note out to the DWARF committee to see if we can streamline the assignment of language codes. As long as there is a source of truth for these, we shouldn't have to wait for DWARF 6 to be published.
The idea has come up before, and now with a motivating case I think it's likely to happen. So if you could hold off a little longer (probably a few days) I can have an answer for you on that point.

Ok I'll wait as long as required, for now I've updated diff regarding my understanding of our yesterday conversation. Thank you for cooperation.

[probinson]

In D47811#1273876, @vvlevchenko wrote:

In D47811#1273052, @probinson wrote:

I've put a note out to the DWARF committee to see if we can streamline the assignment of language codes. As long as there is a source of truth for these, we shouldn't have to wait for DWARF 6 to be published.
The idea has come up before, and now with a motivating case I think it's likely to happen. So if you could hold off a little longer (probably a few days) I can have an answer for you on that point.

Ok I'll wait as long as required, for now I've updated diff regarding my understanding of our yesterday conversation. Thank you for cooperation.

Out of all the current requests to the DWARF committee for a new language code, Kotlin is the only one to request a particular number, so there's a very high probability that you will actually get the requested number.
That said, the DWARF committee does not currently have a process for guaranteeing a language code, and it may be a little while (more than days, less than years) before that's in place.
Therefore, the current state of the patch LGTM, and sorry the DWARF committee can't be more responsive at this time.

[echristo]

In D47811#1274645, @probinson wrote:

In D47811#1273876, @vvlevchenko wrote:

In D47811#1273052, @probinson wrote:

I've put a note out to the DWARF committee to see if we can streamline the assignment of language codes. As long as there is a source of truth for these, we shouldn't have to wait for DWARF 6 to be published.
The idea has come up before, and now with a motivating case I think it's likely to happen. So if you could hold off a little longer (probably a few days) I can have an answer for you on that point.

Ok I'll wait as long as required, for now I've updated diff regarding my understanding of our yesterday conversation. Thank you for cooperation.

Out of all the current requests to the DWARF committee for a new language code, Kotlin is the only one to request a particular number, so there's a very high probability that you will actually get the requested number.
That said, the DWARF committee does not currently have a process for guaranteeing a language code, and it may be a little while (more than days, less than years) before that's in place.
Therefore, the current state of the patch LGTM, and sorry the DWARF committee can't be more responsive at this time.

LGTM as well. I'll... try to poke the committee here.

include/llvm-c/DebugInfo.h

typedef enum {
   LLVMDWARFSourceLanguageC_plus_plus_14,
   LLVMDWARFSourceLanguageFortran03,
   LLVMDWARFSourceLanguageFortran08,
   LLVMDWARFSourceLanguageRenderScript,
   LLVMDWARFSourceLanguageBLISS,
   // Vendor extensions:
   LLVMDWARFSourceLanguageMips_Assembler,
   LLVMDWARFSourceLanguageGOOGLE_RenderScript,
-  LLVMDWARFSourceLanguageBORLAND_Delphi
+  LLVMDWARFSourceLanguageBORLAND_Delphi,
+  LLVMDWARFSourceLanguageLLVM_Kotlin
 } LLVMDWARFSourceLanguage;
 
 /**
  * The amount of debug information to emit.
  */
 typedef enum {
     LLVMDWARFEmissionNone = 0,
     LLVMDWARFEmissionFull,

include/llvm/BinaryFormat/Dwarf.def

 HANDLE_DW_LANG(0x001e, Swift, 5, DWARF)
 HANDLE_DW_LANG(0x001f, Julia, 5, DWARF)
 HANDLE_DW_LANG(0x0020, Dylan, 5, DWARF)
 HANDLE_DW_LANG(0x0021, C_plus_plus_14, 5, DWARF)
 HANDLE_DW_LANG(0x0022, Fortran03, 5, DWARF)
 HANDLE_DW_LANG(0x0023, Fortran08, 5, DWARF)
 HANDLE_DW_LANG(0x0024, RenderScript, 5, DWARF)
 HANDLE_DW_LANG(0x0025, BLISS, 5, DWARF)
 // Vendor extensions:
 HANDLE_DW_LANG(0x8001, Mips_Assembler, 0, MIPS)
 HANDLE_DW_LANG(0x8e57, GOOGLE_RenderScript, 0, GOOGLE)
 HANDLE_DW_LANG(0xb000, BORLAND_Delphi, 0, BORLAND)
+HANDLE_DW_LANG(0xca01, LLVM_Kotlin, 6, LLVM)
 
 // DWARF attribute type encodings.
 HANDLE_DW_ATE(0x01, address, 2, DWARF)
 HANDLE_DW_ATE(0x02, boolean, 2, DWARF)
 HANDLE_DW_ATE(0x03, complex_float, 2, DWARF)
 HANDLE_DW_ATE(0x04, float, 2, DWARF)
 HANDLE_DW_ATE(0x05, signed, 2, DWARF)
 HANDLE_DW_ATE(0x06, signed_char, 2, DWARF)