summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86/accel-tables.ll
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-011-6/+6
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* Reapply: "DebugInfo: Emit only one kind of accelerated access/name table""David Blaikie2019-04-231-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r358931 Reverted in r358997 Seems this change made Apple accelerator tables miss names (because names started respecting the CU NameTableKind GNU & assuming that shouldn't produce accelerated names too), which is never correct (apple accelerator tables don't have separators or CU lists - if present, they must describe all names in all CUs). Original Description: Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 359026
* Revert "DebugInfo: Emit only one kind of accelerated access/name table"David Blaikie2019-04-231-12/+2
| | | | | | | | Regresses some apple_names situations - still investigating. This reverts commit r358931. llvm-svn: 358997
* DebugInfo: Emit only one kind of accelerated access/name tableDavid Blaikie2019-04-221-2/+12
| | | | | | | | | | | | | | | Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 358931
* [MC] Report fatal error for DWARF types for non-ELF object filesJonas Devlieghere2018-08-011-3/+6
| | | | | | | | | | | | | | Getting the DWARF types section is only implemented for ELF object files. We already disabled emitting debug types in clang (r337717), but now we also report an fatal error (rather than crashing) when trying to obtain this section in MC. Additionally we ignore the generate debug types flag for unsupported target triples. See PR38190 for more information. Differential revision: https://reviews.llvm.org/D50057 llvm-svn: 338527
* [DebugInfo] Generate .debug_names section when it makes sensePavel Labath2018-07-201-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes us generate the debug_names section in response to some user-facing commands (previously it was only generated if explicitly selected via the -accel-tables option). My goal was to make this work for DWARF>=5 (as it's an official part of that standard), and also, as an extension, for DWARF<5 if one is explicitly tuning for lldb as a debugger (because it brings a large performance improvement there). This is slightly complicated by the fact that the debug_names tables are incompatible with the DWARF v4 type units (they assume that the type units are in the debug_info section), and unfortunately, right now we generate DWARF v4-style type units even for -gdwarf-5. For this reason, I disable all accelerator tables if the user requested type unit generation. I do this even for apple tables, as they have the same problem (in fact generating type units for apple targets makes us crash even before we get around to emitting the accelerator tables). Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49420 llvm-svn: 337544
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* Don't emit apple accelerator tables on non-darwin targetsPavel Labath2018-01-171-0/+49
Summary: Currently -glldb turns on emission of apple tables on all targets, but lldb is only really capable of consuming them on darwin. Furthermore, making lldb consume these tables is not straight-forward because of the differences in how the debug info is distributed on darwin vs. elf targets. The darwin debug model assumes that the debug info (along with accelerator tables) will either remain in the .o files or it will be linked into a dsym bundle by a linker that knows how to merge these tables. In the elf world, all present linkers will simply concatenate these accelerator tables into the shared object. Since the tables are not self-terminating, this renders the tables unusable, as the debugger cannot pry the individual tables apart anymore. It might theoretically be possible to make the tables work with split dwarf, as that is somewhat similar to the apple .o model, but unfortunately right now the combination of -glldb and -gsplit-dwarf produces broken object files. Until these issues are resolved there is no point in emitting the apple tables for these targets. At best, it wastes space; at worst, it breaks compilation and prevents the user from getting other benefits of -glldb. Reviewers: probinson, aprantl, dblaikie Subscribers: emaste, dim, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41986 llvm-svn: 322633
OpenPOWER on IntegriCloud