Commit Graph

7 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith 9dd4e4e63a DebugInfo: Metadata constructs now start with DI*
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week.  This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.

llvm-svn: 236121
2015-04-29 16:40:08 +00:00
Duncan P. N. Exon Smith f04be1fb3a DebugInfo: Move new hierarchy into place (clang)
Update testcases for LLVM change in r231082 to use the new debug info
hierarchy.

llvm-svn: 231083
2015-03-03 17:25:55 +00:00
Duncan P. N. Exon Smith b3a66691f8 IR: Make metadata typeless in assembly, clang side
Match LLVM changes from r224257.

llvm-svn: 224259
2014-12-15 19:10:08 +00:00
NAKAMURA Takumi 12fb0057d1 clang/test/CodeGenCXX/debug-info-cxx1y.cpp: Add %itanium_abi_triple for incompatible MS targets.
llvm-svn: 221741
2014-11-11 23:51:53 +00:00
David Blaikie 42edade9d9 PR16091 continued: Debug Info for member functions with undeduced return types.
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.

GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.

Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.

Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).

Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)

So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.

At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...

llvm-svn: 221704
2014-11-11 20:44:45 +00:00
Rafael Espindola 925213b0fa Add 'not' to commands that are expected to fail.
This is at least good documentation, but also opens the possibility of
using pipefail.

llvm-svn: 185652
2013-07-04 16:16:58 +00:00
David Blaikie 22c460a051 PR16091: Error when attempting to emit debug info for undeduced auto return types
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.

llvm-svn: 182673
2013-05-24 21:24:35 +00:00