Add new compiler flag to enable the generation of dwarf accelerator tables

[tberghammer]

Summary

Add new compiler flag to enable the generation of dwarf accelerator tables

The dwarf accelerator tables already generated on darwin platforms. This CL ands a new flag to clang to make it possible to enable the generation of these tables on other platforms also.

Note: Currently the accelerator table generation code isn't working when split dwarf is enabled for several reasons (accelerator tables aren't copied to dwo file, they contain relocation entries for the .debug_str.dwo sections). These issues should be addressed separately.

[dblaikie]

Test case?

[tberghammer]

Add a test (I have no experience writing clang tests so please let me know if I approach is wrong)

[tberghammer]

Adding the dwarf accelerator tables is increasing the size of libclang.so
(ToT) by ~12% so I don't think we want to generate them by default. Also
these sections are not specified by any dwarf standard at the moment so
emitting them by default would be strange in my opinion.

[probinson]

So, currently you get accel tables by default for platforms that "tune" for LLDB, currently Darwin and FreeBSD.
Are you wanting to use LLDB on another platform, or did you want accel tables for a different debugger?

(Eventually I will have a chance to expose the "tuning" up through Clang, and if you're running LLDB on another platform, that will be the easier way to get what you want.)

test/Driver/dwarf-accel.c

4

Normally you'd just pipe the output to FileCheck rather than write a temp file, because that's more efficient. There are lots of examples to crib from in other tests.

[tberghammer]

In D14354#282870, @probinson wrote:

So, currently you get accel tables by default for platforms that "tune" for LLDB, currently Darwin and FreeBSD.
Are you wanting to use LLDB on another platform, or did you want accel tables for a different debugger?

(Eventually I will have a chance to expose the "tuning" up through Clang, and if you're running LLDB on another platform, that will be the easier way to get what you want.)

We are using LLDB for Android (as part of Android Studio) and some of us also use if for Linux (I hope we can get higher adaptation soon).

test/Driver/dwarf-accel.c

4

I copied this pattern from split-dwarf.c but will check out how can I do it with piping

[probinson]

In D14354#282988, @tberghammer wrote:

In D14354#282870, @probinson wrote:

So, currently you get accel tables by default for platforms that "tune" for LLDB, currently Darwin and FreeBSD.
Are you wanting to use LLDB on another platform, or did you want accel tables for a different debugger?

(Eventually I will have a chance to expose the "tuning" up through Clang, and if you're running LLDB on another platform, that will be the easier way to get what you want.)

We are using LLDB for Android (as part of Android Studio) and some of us also use if for Linux (I hope we can get higher adaptation soon).

Okay. I'll try to get the tuning-in-Clang task moved higher up my list, because if you had that you wouldn't need this patch.

lib/Driver/Tools.cpp

3880

This is not how other similar options work (-ggnu-pubnames, -gdwarf-aranges). Do you have a particular reason why this one should imply -g?

[tberghammer]

If you plan to do the "tuning" in clang in the near future then we can abandon this change in favor of that one

lib/Driver/Tools.cpp

3880

No, I am perfectly happy if it don't imply '-g'

[probinson]

I have an internal release freeze coming up in a couple of weeks, but I should be able to spend time on exposing the "tuning" in clang after that. I don't mind this patch going in if you're not able to wait.

[dblaikie]

Or Tamas can write the tuning patch - it seems like it'd be relatively
straightforward. Perhaps you can give an idea of what you think it'd look
like, Paul (what the command line syntax would be, etc)

[probinson]

In D14354#285546, @dblaikie wrote:

Or Tamas can write the tuning patch - it seems like it'd be relatively
straightforward. Perhaps you can give an idea of what you think it'd look
like, Paul (what the command line syntax would be, etc)

My thought was: There is already a -ggdb option, which today means the same as -g. But, it could mean what GCC documents it to mean: "Produce debugging information for use by GDB... including GDB extensions if at all possible." That is, tune the DWARF for GDB.
We could then add the corresponding options -glldb (tune for LLDB) and -gsce (tune for SCE debugger).
All of these would imply -g of course, and pass along the requested tuning to LLVM. Clang already maintains a debug-info "level" in the CodeGenOpts, and the tuning seems like it would fit right alongside. There are doubtless places in Clang where we would end up taking advantage of this.
With the tuning passed down from Clang to LLVM, there is already a place in LLVM to turn on the accel tables for LLDB, and so for the use case described in this patch, exposing tuning from the driver solves the problem.

I did have a patch at one point, but in the meantime somebody has overhauled -g* processing and there is still some question how to pass down the tuning in a way that is robust for LTO.

I'm fine with somebody else doing the patch if it's useful to them and desirable in a shorter timescale than I can provide right now.

[echristo]

I think the basic idea on how to do this is to make sure all of the information is there from the front end and have the backend select how to emit based on the code gen flag for this. libLTO is terrible for this, but the schemes working for lld are showing progress in passing information around for code generation time.

-eric

[tberghammer]

I am not in a hurry with getting this change in, but happy to take a look for enabling the tuning if somebody can explain me what you mean under it (I have almost no llvm/clang development experience)

[probinson]

The patch to expose debugger tuning to Clang was finished in r256104. If you use the new -glldb option to clang, you should get these accelerator tables. I'm assuming you're using LLDB because I don't think any other debugger makes use of those tables, although that's admittedly a guess on my part.
If LLDB is the default system debugger for some target other than Darwin, then we should fiddle with the defaulting.

If -glldb satisfies your needs, then you can probably just abandon this review.

[tberghammer]

Thank you for adding the new debugger tuning feature. I am using LLDB so "-glldb" will work for me perfectly.

There is one thing we might consider is that the accelerator tables increasing the size of the binary by ~10% (measured on clang) so I don't know if we want to enable them by default or not on any platform.

include/clang/Driver/Options.td

def gno_record_gcc_switches : Flag<["-"], "gno-record-gcc-switches">,
   Group<g_flags_Group>;
 def gstrict_dwarf : Flag<["-"], "gstrict-dwarf">, Group<g_flags_Group>;
 def gno_strict_dwarf : Flag<["-"], "gno-strict-dwarf">, Group<g_flags_Group>;
 def gcolumn_info : Flag<["-"], "gcolumn-info">, Group<g_flags_Group>;
 def gno_column_info : Flag<["-"], "gno-column-info">, Group<g_flags_Group>;
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group<g_flags_Group>;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group<g_flags_Group>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group<g_flags_Group>;
+def gdwarf_accel_tables : Flag<["-"], "gdwarf-accel-tables">, Group<g_flags_Group>;
 def gmodules : Flag <["-"], "gmodules">, Group<f_Group>,
   HelpText<"Generate debug info with external references to clang modules"
            " or precompiled headers">;
 def headerpad__max__install__names : Joined<["-"], "headerpad_max_install_names">;
 def help : Flag<["-", "--"], "help">, Flags<[CC1Option,CC1AsOption]>,
   HelpText<"Display available options">;
 def index_header_map : Flag<["-"], "index-header-map">, Flags<[CC1Option]>,
   HelpText<"Make the next included directory (-I or -F) an indexer header map">;

lib/Driver/Tools.cpp

#endif
   // splitting and extraction.
   // FIXME: Currently only works on Linux.
   if (getToolChain().getTriple().isOSLinux() && SplitDwarfArg) {
     DebugInfoKind = CodeGenOptions::LimitedDebugInfo;
     CmdArgs.push_back("-backend-option");
     CmdArgs.push_back("-split-dwarf=Enable");
   }
 
+  // -gdwarf-accel-tables should turn on -g and enable the genereation of the
+  // dwarf acceleration tables in the backend.
+  if (Args.hasArg(options::OPT_gdwarf_accel_tables)) {
+    DebugInfoKind = CodeGenOptions::LimitedDebugInfo;
+    CmdArgs.push_back("-backend-option");
+    CmdArgs.push_back("-dwarf-accel-tables=Enable");
+  }
+
   // After we've dealt with all combinations of things that could
   // make DebugInfoKind be other than None or DebugLineTablesOnly,
   // figure out if we need to "upgrade" it to standalone debug info.
   // We parse these two '-f' options whether or not they will be used,
   // to claim them even if you wrote "-fstandalone-debug -gline-tables-only"
   bool NeedFullDebug = Args.hasFlag(options::OPT_fstandalone_debug,
                                     options::OPT_fno_standalone_debug,
                                     getToolChain().GetDefaultStandaloneDebug());

test/Driver/dwarf-accel.c

+// Check that -gdwarf-accel-tables requests the emission of the accelerator tables
+//
+// RUN: %clang -target x86_64-unknown-linux-gnu -gdwarf-accel-tables -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK < %t %s
+//
+// CHECK: -dwarf-accel-tables=Enable