[PATCH] Set a debugger "target" to guide DWARF choices

[David Blaikie]

On Thu, Jun 25, 2015 at 11:17 AM, Paul Robinson <
Paul_Robinson at playstation.sony.com> wrote:

> ================
> Comment at: include/llvm/CodeGen/CommandFlags.h:236
> @@ +235,3 @@
> +cl::opt<DebuggerKind>
> +DebuggerTuning("debugger-tune",
> +               cl::desc("Tune debug info for a particular debugger"),
> ----------------
> dblaikie wrote:
> > What's the command line argument for? I mean convenience of testing
> LLVM, a bit, but in general we don't want to use backend options like this
> when actually interacting with LLVM from Clang and other frontends. This
> should probably end up as a part of the CU debug info metadata? Or a
> module-level debug info metadata flag? (ala DWARF version)
> The command line option is precisely for testing; it is not how Clang
> communicates to LLVM.
> CommandFlags.h exists to define command-line options for the tools (llc,
> opt etc) only.  It does not define a command-line option that is accessible
> to Clang.
> Clang will set the TargetOptions field directly.
>

Setting target options makes things a bit hard to test (it's hard to test
that Clang does this correctly in a clang test - since it's just API, not
part of the bitcode, etc) and difficult to deal with in LTO (the command
line flag would be passed to the compilation, but needed by the linking
step).


>
>
> ================
> Comment at: test/DebugInfo/X86/dwarf-public-names.ll:42
> @@ -41,3 +41,3 @@
>  ; NOPUB: debug_pubnames
> -; NOPUB: {{^$}}
> +; NOPUB-NEXT: {{^$}}
>
> ----------------
> dblaikie wrote:
> > what happened to these two checks in this test?
> As originally written, this check does not fail if there is actually a
> debug_pubnames section, because it didn't insist that the empty line was
> immediately following the "debug_pubnames" header line.  Instead it would
> match the empty line at the end of the debug_pubnames dump, and pass.
> I made the same change on the LINUX path just for consistency.
>

Can you make this change ahead of time to demonstrate that it's an
independent/improvement change? (if you've already committed, no worries -
something to consider for future commits)


>
> This test update could actually be committed independently if you'd
> rather, as it's fixing a bug in the test rather than actually testing
> something I did in the rest of the patch.
>
> http://reviews.llvm.org/D8506
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150625/eeebfce6/attachment.html>