[Driver] Pass -gno-column-info instead of -dwarf-column-info

Making -g[no-]column-info opt out reduces the length of a typical CC1 command line.
Additionally, in a non-debug compile, we won't see -d

[Driver] Pass -gno-column-info instead of -dwarf-column-info

Making -g[no-]column-info opt out reduces the length of a typical CC1 command line.
Additionally, in a non-debug compile, we won't see -dwarf-column-info.

show more ...

[Debug] Annotate compiler generated range-for loop variables.

Summary:
This change aims to simplify debugging by annotating the range-for loop artificial variables (range, begin, end) with the scope

[Debug] Annotate compiler generated range-for loop variables.

Summary:
This change aims to simplify debugging by annotating the range-for loop artificial variables (range, begin, end) with the scope depth.


Reviewers: rsmith, dblaikie

Reviewed By: dblaikie

Subscribers: dblaikie, cfe-commits

Tags: #debug-info

Differential Revision: https://reviews.llvm.org/D42813

llvm-svn: 325175

show more ...

Stop messing with the 'g' group of options in CompilerInvocation.

With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request de

Stop messing with the 'g' group of options in CompilerInvocation.

With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.

Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.

Differential Revision: http://reviews.llvm.org/D13221

llvm-svn: 249655

show more ...

DI: Update testcases for LLVM assembly change

Update testcases after LLVM change r243774.

Most of these had no need to check `tag:` field, but did so as a way of
getting to the `name:` field. In a

DI: Update testcases for LLVM assembly change

Update testcases after LLVM change r243774.

Most of these had no need to check `tag:` field, but did so as a way of
getting to the `name:` field. In a few cases I've converted the `tag:`
checks to `arg:` or `CHECK-NOT: arg:`.

llvm-svn: 243775

show more ...

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
comm

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

show more ...

DebugInfo: Move new hierarchy into place (clang)

Update testcases for LLVM change in r231082 to use the new debug info
hierarchy.

llvm-svn: 231083

Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).

Several pieces of code were relying on implicit debug location setting
which usuall

Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).

Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225956

show more ...

Revert "DebugInfo: Generalize debug info location handling" and related commits

This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues w

Revert "DebugInfo: Generalize debug info location handling" and related commits

This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.

I'll work up some test cases and fixes before recommitting this.

llvm-svn: 225555

show more ...

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fi

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000

show more ...

Revert "DebugInfo: Generalize debug info location handling"

Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn

Revert "DebugInfo: Generalize debug info location handling"

Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970

show more ...

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fi

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224941

show more ...

Revert "DebugInfo: Generalize debug info location handling"

Fails an ASan bootstrap - I'll try to reproduce locally & sort that out
before recommitting.

This reverts commit r224385.

llvm-svn: 2244

Revert "DebugInfo: Generalize debug info location handling"

Fails an ASan bootstrap - I'll try to reproduce locally & sort that out
before recommitting.

This reverts commit r224385.

llvm-svn: 224441

show more ...

DebugInfo: Generalize debug info location handling

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several co

DebugInfo: Generalize debug info location handling

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224385

show more ...

IR: Make metadata typeless in assembly, clang side

Match LLVM changes from r224257.

llvm-svn: 224259

DebugInfo: Omit scopes in -gmlt to reduce metadata size (on disk and in memory)

I haven't done any actual impact analysis of this change as it's a
strict improvement, but I'd be curious to know how

DebugInfo: Omit scopes in -gmlt to reduce metadata size (on disk and in memory)

I haven't done any actual impact analysis of this change as it's a
strict improvement, but I'd be curious to know how much it helps.

llvm-svn: 220408

show more ...

Revert "Revert "DI: LLVM schema change: fold constants into string""

This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.

--

Update debug info testcases f

Revert "Revert "DI: LLVM schema change: fold constants into string""

This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.

--

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm-svn: 219011

show more ...

Revert "DI: LLVM schema change: fold constants into string"

This reverts commit r218913 while I investigate some bots.

llvm-svn: 218917

DI: LLVM schema change: fold constants into string

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm

DI: LLVM schema change: fold constants into string

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm-svn: 218913

show more ...

DebugInfo: Provide scopes for C++11 range-for loop variables similar to r216288 (which was for plain-for loop condition variables).

llvm-svn: 216291

DebugInfo: Scope for condition variables more narrowly than the loop variable.

for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of th

DebugInfo: Scope for condition variables more narrowly than the loop variable.

for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of the loop, including any
variable declared inside the loop condition.

llvm-svn: 216288

show more ...

test case hygiene.

llvm-svn: 199017

Debug info: An if condition now creates a lexical scope of its own.
Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.

rdar://problem/

Debug info: An if condition now creates a lexical scope of its own.
Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.

rdar://problem/14024005

llvm-svn: 183597

show more ...