[PATCH] Add new debug kind LocTrackingOnly.

[Diego Novillo]

On Mon, Jun 23, 2014 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote:

> ================
> Comment at: lib/CodeGen/CGDebugInfo.cpp:378
> @@ -377,2 +377,3 @@
>        CGM.getCodeGenOpts().DwarfDebugFlags, RuntimeVers,
> SplitDwarfFilename,
> -      DebugKind == CodeGenOptions::DebugLineTablesOnly
> +      (DebugKind == CodeGenOptions::DebugLineTablesOnly ||
> +       DebugKind == CodeGenOptions::LocTrackingOnly)
> ----------------
> I'd use <= here, though it doesn't really matter since this metadata
> should never end up being read/used in the LocTrackingOnly situation.
>

Done.


>
> ================
> Comment at: lib/Frontend/CompilerInvocation.cpp:571
> @@ +570,3 @@
> +      Opts.setDebugInfo(CodeGenOptions::LocTrackingOnly);
> +      Opts.DebugColumnInfo = true;
> +    }
> ----------------
> You only want to track column info if the user didn't request debug info?
> That seems like a strange limitation - the diagnostic quality will
> improve/change in non-debug builds?
>

Yeah. I forgot to comment about this one. I am not sure what to do when the
user requests debug info. If I force column tracking, I will be changing
the output when -Rpass is used. I was hesitant about trying to introduce a
tracking-only option for column info, as that seems more convoluted than
what I have now.

My question then. Does it matter if -Rpass forces column-info on a regular
debug build? Other than the .loc entries having non-zero column indicators,
I didn't notice any other change.  Not sure how much we want to avoid that,
though.



>
> ================
> Comment at: test/Frontend/optimization-remark.c:11
> @@ +10,3 @@
> +// -Rpass should produce source location annotations.
> +// CHECK: , !dbg !
> +//
> ----------------
> You should be able to test for the absence of any type information, for
> example (at a guess: CHECK-NOT: DW_TAG_basic_type) now that you've changed
> those couple of == GMLT to <= GMLT. If you undo those changes, add the
> CHECK-NOT I mentioned, verify the test fails, then reapply the changes,
> that'd be great.
>

Indeed. I added a test for DW_TAG_base_type to the test.


Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140623/eb2fb63b/attachment.html>