[DebugInfo] Generate .debug_names section when it makes sense
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
2018-07-20 20:59:05 +08:00
|
|
|
; Verify the emission of accelerator tables for various targets for the DWARF<=4 case
|
|
|
|
|
|
|
|
|
|
; Darwin has the apple tables unless we specifically tune for gdb
|
|
|
|
|
; RUN: llc -mtriple=x86_64-apple-darwin12 -filetype=obj < %s \
|
|
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=APPLE %s
|
|
|
|
|
; RUN: llc -mtriple=x86_64-apple-darwin12 -filetype=obj -debugger-tune=gdb < %s \
|
|
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=NONE %s
|
|
|
|
|
|
|
|
|
|
; Linux does has debug_names tables only if we explicitly tune for lldb
|
|
|
|
|
; RUN: llc -mtriple=x86_64-pc-linux -filetype=obj < %s \
|
|
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=NONE %s
|
|
|
|
|
; RUN: llc -mtriple=x86_64-pc-linux -filetype=obj -debugger-tune=lldb < %s \
|
|
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=DEBUG_NAMES %s
|
|
|
|
|
|
2018-08-01 20:53:06 +08:00
|
|
|
; No accelerator tables if type units are enabled, as DWARF v4 type units are
|
|
|
|
|
; not compatible with accelerator tables.
|
[DebugInfo] Generate .debug_names section when it makes sense
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
2018-07-20 20:59:05 +08:00
|
|
|
; RUN: llc -mtriple=x86_64-pc-linux -filetype=obj -generate-type-units -debugger-tune=lldb < %s \
|
|
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=NONE %s
|
2018-08-01 20:53:06 +08:00
|
|
|
|
|
|
|
|
; Debug types are ignored for non-ELF targets which means it shouldn't affect
|
|
|
|
|
; accelerator table generation.
|
[DebugInfo] Generate .debug_names section when it makes sense
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
2018-07-20 20:59:05 +08:00
|
|
|
; RUN: llc -mtriple=x86_64-apple-darwin12 -generate-type-units -filetype=obj < %s \
|
2018-08-01 20:53:06 +08:00
|
|
|
; RUN: | llvm-readobj -sections - | FileCheck --check-prefix=APPLE %s
|
[DebugInfo] Generate .debug_names section when it makes sense
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
2018-07-20 20:59:05 +08:00
|
|
|
|
|
|
|
|
; APPLE-NOT: debug_names
|
|
|
|
|
; APPLE: apple_names
|
|
|
|
|
; APPLE-NOT: debug_names
|
|
|
|
|
|
|
|
|
|
; NONE-NOT: apple_names
|
|
|
|
|
; NONE-NOT: debug_names
|
|
|
|
|
|
|
|
|
|
; DEBUG_NAMES-NOT: apple_names
|
|
|
|
|
; DEBUG_NAMES: debug_names
|
|
|
|
|
; DEBUG_NAMES-NOT: apple_names
|
Don't emit apple accelerator tables on non-darwin targets
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
2018-01-17 19:52:13 +08:00
|
|
|
|
|
|
|
|
@var = thread_local global i32 0, align 4, !dbg !0
|
|
|
|
|
|
|
|
|
|
; Function Attrs: norecurse nounwind readnone uwtable
|
|
|
|
|
define void @_Z3funv() local_unnamed_addr #0 !dbg !11 {
|
|
|
|
|
ret void, !dbg !14
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Function Attrs: norecurse uwtable
|
|
|
|
|
define weak_odr hidden i32* @_ZTW3var() local_unnamed_addr #1 {
|
|
|
|
|
ret i32* @var
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
attributes #0 = { norecurse nounwind readnone uwtable }
|
|
|
|
|
attributes #1 = { norecurse uwtable }
|
|
|
|
|
|
|
|
|
|
!llvm.dbg.cu = !{!2}
|
|
|
|
|
!llvm.module.flags = !{!7, !8, !9}
|
|
|
|
|
!llvm.ident = !{!10}
|
|
|
|
|
|
|
|
|
|
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
|
|
|
|
|
!1 = distinct !DIGlobalVariable(name: "var", scope: !2, file: !3, line: 1, type: !6, isLocal: false, isDefinition: true)
|
|
|
|
|
!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "clang version 7.0.0 (trunk 322268) (llvm/trunk 322267)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5)
|
|
|
|
|
!3 = !DIFile(filename: "debugger-tune.cpp", directory: "/tmp")
|
|
|
|
|
!4 = !{}
|
|
|
|
|
!5 = !{!0}
|
|
|
|
|
!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
|
|
|
|
|
!7 = !{i32 2, !"Dwarf Version", i32 4}
|
|
|
|
|
!8 = !{i32 2, !"Debug Info Version", i32 3}
|
|
|
|
|
!9 = !{i32 1, !"wchar_size", i32 4}
|
|
|
|
|
!10 = !{!"clang version 7.0.0 (trunk 322268) (llvm/trunk 322267)"}
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
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
2018-05-09 10:40:45 +08:00
|
|
|
!11 = distinct !DISubprogram(name: "fun", linkageName: "_Z3funv", scope: !3, file: !3, line: 2, type: !12, isLocal: false, isDefinition: true, scopeLine: 2, flags: DIFlagPrototyped, isOptimized: true, unit: !2, retainedNodes: !4)
|
Don't emit apple accelerator tables on non-darwin targets
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
2018-01-17 19:52:13 +08:00
|
|
|
!12 = !DISubroutineType(types: !13)
|
|
|
|
|
!13 = !{null}
|
|
|
|
|
!14 = !DILocation(line: 2, column: 13, scope: !11)
|
|
|
|
|
|