Any properly written dwarf reader will ignore attributes it doesn't understand, and hence in theory there should be no need for a - gdwarf-2+ option. You can just emit the new info by default and everything should work.
The problem is that the switch will also change what is contained in the DW_AT_name attributes. For example what is today written as "hello__my_array_type" will become "hello.my_array_type". Previously we were using double underscores as component separator, and we would like to use dots instead.
Right now, external tools (such as gdb, [lib]addr2line, etc) which read dwarf-2 for Ada need to have "demangling" functions to transform the contents of DW_AT_name into user-friendly strings. We want to allow them to get rid of these Ada-specific demanglers, but in the meantime we don't want the existing demanglers to choke on unexpected contents of DW_AT_name.
If you are proposing -gdwarf-2+ because you want to have support for both the old and new Ada debug info, then I think that is a misuse of the debug+ convention. You aren't really adding extensions. You are just changing from stabs hacks to proper dwarf info. Also, having the -gdwarf-2+ option may confuse people into thinking that they need it for C++ (which is where the + originally came from).
Understood.
Not having both means that gdb patches need to get installed first, then the gcc patches, and then you document that gcc version X requires gdb version Y.
I'll check with the gdb-Ada experts what it takes exactly to support this.
Ordinarily this shouldn't be a problem, but I realize that historically gdb support for Ada hasn't been as good as it should be. If we really need both old and new formats, I'd suggest a -f option first, maybe something like -fada-stabs-encodings to get the old format.
OK, no problem for using -fada-stabs-encodings. Thank you for your comments! Nicolas