On Thu, Nov 13, 2014 at 2:07 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Nov 13, 2014 at 01:08:44PM +0100, Richard Biener wrote: >> On Thu, Nov 13, 2014 at 12:17 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Thu, Nov 13, 2014 at 12:08:01PM +0100, Richard Biener wrote: >> >> Btw, I have nothing against changing TRANSLATION_UNIT_LANGUAGE >> >> to DW_LANG_* directly - we only use it for choosing the language >> >> of the dwarf unit. This would of course mean to change its initialization >> >> from >> >> >> >> TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name; >> >> >> >> to sth like >> >> >> >> TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.dw_lang; >> >> >> >> which means adding a langhook (thus more similar to your original >> >> patch). >> > >> > But that would mean having to include dwarf2 headers in every FE. >> >> Don't see what would be bad about this, but well... > > I think strings are better than DWARF constants for middle-end thing, > say if DWARF doesn't make a difference between some language variants but > something different in the middle-end wants, or updating all the backends to > test when C++17 is released and DWARF assigns a language code for it > would be also weird. > > If you want an integer instead of strings, it better should be some enum > with major and minor parts in it, so that one can easily test if it is > a C++ family, C family, C/C++ family, Fortran family etc. Still, that would > make things hard for third party frontends, which wouldn't know what values > to use if they don't have a language code in DWARF.
I'm fine with the string solution as well. Just properly transfer whatever info you want through the translation unit decl and LTO stream it. Richard. > Jakub
