Before this change -gdwarf-5 on AIX will cause backend crash, because
some DWARF5 sections are not defined in XCOFF.
Explicitly statement -gdwarf-5 as unsupported in frontend on AIX.
Pick up a few more codegen parametres from downstream. The DWARF version matchesthe GCC config.
DWARF version 4, Math Errno handling, ObjC ABI handling, and debug handling.
Reviewed By: nielx
Differential Revision: https://reviews.llvm.org/D159409
`clang` currently defaults to DWARF 2 on Solaris. This dates back to LLVM
3.8.0. I suspect this is related to `gcc/config/sol2.cc`
(`solaris_override_options`) doing the same unless
`HAVE_LD_EH_FRAME_CIEV3`. The latter is 1 on both Solaris 11.3 and 11.4,
so the workaround has become irrelevant these days.
This patch removes the Solaris override, adjusting affected testcases
accordingly.
Tested on `amd64-pc-solaris2.11` (`Release` and `Debug` builds) and
`sparcv9-sun-solaris2.11` (`Release` build).
Differential Revision: https://reviews.llvm.org/D159352
Neither LLDB nor GDB seem to work with DWARF 5 debug information on
Windows right now.
This applies the same change as in
9c6272861032f511a23784ce0c5cc8f6ac2f625b (Default to DWARFv4 on Windows)
to the MinGW driver too.
Differential Revision: https://reviews.llvm.org/D119326
When the Dwarf Version metadata was initially added (r184276) there was
no support for Module::Max - though the comment suggested that was the
desired behavior. The original behavior was Module::Warn which would
warn and then pick whichever version came first - which is pretty
arbitrary/luck-based if the consumer has some need for one version or
the other.
Now that the functionality's been added (r303590) this change updates
the implementation to match the desired goal.
The general logic here is - if you compile /some/ of your program with a
more recent DWARF version, you must have a consumer that can handle it,
so might as well use it for /everything/.
The only place where this might fall down is if you have a need to use
an old tool (supporting only the older DWARF version) for some subset of
your program. In which case now it'll all be the higher version. That
seems pretty narrow (& the inverse could happen too - you specifically
/need/ the higher DWARF version for some extra expressivity, etc, in
some part of the program)
Summary:
If you're using the Microsoft ABI, chances are that you want PDBs and
codeview debug info. Currently, everyone has to remember to specific
-gcodeview by default, when it would be nice if the standard -g option
did the right thing by default.
Also, do some related cleanup of -cc1 options. When targetting the MS
C++ ABI, we probably shouldn't pass -debugger-tuning=gdb. We were also
passing -gcodeview twice, which is silly.
Reviewers: smeenai, zturner
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54499
llvm-svn: 346907
the front end as well.
Note that DWARF5 isn't finalized and any feature support is subject to
change and accepting of the option doesn't mean we're supporting the
full range of the current standard.
llvm-svn: 256516
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
llvm-svn: 244097
Darwin systems currently do not support dwarf version 3 or above. When we are
ready, we can bump the default to gdwarf-4 for Darwin.
For other systems, the default is dwarf version 3, if everything goes smoothly,
we can bump the version to 4.
rdar://13591116
llvm-svn: 185483
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
llvm-svn: 184276
