Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #83360

Merged
merged 24 commits into from
Mar 22, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
cce258b
Make NonNull::as_ref (and friends) return refs with unbound lifetimes
thomcc Jan 7, 2021
c89e643
Fix invalid slice access in String::retain
SkiFire13 Feb 26, 2021
7539626
Move `std::sys::unix::platform` to `std::sys::unix::ext`
CDirkx Mar 1, 2021
5176f67
slice: Stabilize IterMut::as_slice.
emilio Mar 4, 2021
93fda34
stabilize feature(osstring_ascii)
fogti Mar 5, 2021
a2e9374
Move debuginfo docs from `doc.rs` module to `doc.md` file
camelid Mar 20, 2021
dc240fa
Cleanup LLVM debuginfo module docs
camelid Mar 20, 2021
4002171
Download a more recent LLVM version if `src/version` is modified
jyn514 Mar 21, 2021
0acdada
Bump osstring_ascii stabilization version to 1.53.0.
m-ou-se Mar 21, 2021
236c0cf
implement TrustedLen and TrustedRandomAccess for VecDeque iterators
the8472 Jan 31, 2021
1438207
use BITS constant
the8472 Jan 31, 2021
895d7a9
implement TrustedRandomAccess for Ranges over int types
the8472 Jan 31, 2021
08a1dd2
implement TrustedRandomAccess for array::IntoIter
the8472 Jan 31, 2021
bfae41d
Fix ICE with `use clippy::a::b;`
camelid Mar 21, 2021
2bd7c1b
Bump slice_iter_mut_as_slice stable version.
m-ou-se Mar 21, 2021
e9398bc
Rollup merge of #80193 - zseri:stabilize-osstring-ascii, r=m-ou-se
Dylan-DPC Mar 22, 2021
ad8aa18
Rollup merge of #80771 - thomcc:nonnull-refmut, r=dtolnay
Dylan-DPC Mar 22, 2021
29a53e6
Rollup merge of #81607 - the8472:trustedrandomaccess-all-the-things, …
Dylan-DPC Mar 22, 2021
da143d3
Rollup merge of #82554 - SkiFire13:fix-string-retain-unsoundness, r=m…
Dylan-DPC Mar 22, 2021
c66d66e
Rollup merge of #82686 - CDirkx:unix-platform, r=m-ou-se
Dylan-DPC Mar 22, 2021
34285de
Rollup merge of #82771 - emilio:iter-mut-as-slice, r=m-ou-se
Dylan-DPC Mar 22, 2021
85f16fb
Rollup merge of #83329 - camelid:debuginfo-doc-cleanup, r=davidtwco
Dylan-DPC Mar 22, 2021
ea5ba76
Rollup merge of #83336 - camelid:tool-mod-ice, r=petrochenkov
Dylan-DPC Mar 22, 2021
790c2ad
Rollup merge of #83350 - jyn514:llvm-version, r=Mark-Simulacrum
Dylan-DPC Mar 22, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
180 changes: 180 additions & 0 deletions compiler/rustc_codegen_llvm/src/debuginfo/doc.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,180 @@
# Debug Info Module

This module serves the purpose of generating debug symbols. We use LLVM's
[source level debugging](https://llvm.org/docs/SourceLevelDebugging.html)
features for generating the debug information. The general principle is
this:

Given the right metadata in the LLVM IR, the LLVM code generator is able to
create DWARF debug symbols for the given code. The
[metadata](https://llvm.org/docs/LangRef.html#metadata-type) is structured
much like DWARF *debugging information entries* (DIE), representing type
information such as datatype layout, function signatures, block layout,
variable location and scope information, etc. It is the purpose of this
module to generate correct metadata and insert it into the LLVM IR.

As the exact format of metadata trees may change between different LLVM
versions, we now use LLVM
[DIBuilder](https://llvm.org/docs/doxygen/html/classllvm_1_1DIBuilder.html)
to create metadata where possible. This will hopefully ease the adaption of
this module to future LLVM versions.

The public API of the module is a set of functions that will insert the
correct metadata into the LLVM IR when called with the right parameters.
The module is thus driven from an outside client with functions like
`debuginfo::create_local_var_metadata(bx: block, local: &ast::local)`.

Internally the module will try to reuse already created metadata by
utilizing a cache. The way to get a shared metadata node when needed is
thus to just call the corresponding function in this module:

let file_metadata = file_metadata(cx, file);

The function will take care of probing the cache for an existing node for
that exact file path.

All private state used by the module is stored within either the
CrateDebugContext struct (owned by the CodegenCx) or the
FunctionDebugContext (owned by the FunctionCx).

This file consists of three conceptual sections:
1. The public interface of the module
2. Module-internal metadata creation functions
3. Minor utility functions


## Recursive Types

Some kinds of types, such as structs and enums can be recursive. That means
that the type definition of some type X refers to some other type which in
turn (transitively) refers to X. This introduces cycles into the type
referral graph. A naive algorithm doing an on-demand, depth-first traversal
of this graph when describing types, can get trapped in an endless loop
when it reaches such a cycle.

For example, the following simple type for a singly-linked list...

```
struct List {
value: i32,
tail: Option<Box<List>>,
}
```

will generate the following callstack with a naive DFS algorithm:

```
describe(t = List)
describe(t = i32)
describe(t = Option<Box<List>>)
describe(t = Box<List>)
describe(t = List) // at the beginning again...
...
```

To break cycles like these, we use "forward declarations". That is, when
the algorithm encounters a possibly recursive type (any struct or enum), it
immediately creates a type description node and inserts it into the cache
*before* describing the members of the type. This type description is just
a stub (as type members are not described and added to it yet) but it
allows the algorithm to already refer to the type. After the stub is
inserted into the cache, the algorithm continues as before. If it now
encounters a recursive reference, it will hit the cache and does not try to
describe the type anew.

This behavior is encapsulated in the 'RecursiveTypeDescription' enum,
which represents a kind of continuation, storing all state needed to
continue traversal at the type members after the type has been registered
with the cache. (This implementation approach might be a tad over-
engineered and may change in the future)


## Source Locations and Line Information

In addition to data type descriptions the debugging information must also
allow to map machine code locations back to source code locations in order
to be useful. This functionality is also handled in this module. The
following functions allow to control source mappings:

+ `set_source_location()`
+ `clear_source_location()`
+ `start_emitting_source_locations()`

`set_source_location()` allows to set the current source location. All IR
instructions created after a call to this function will be linked to the
given source location, until another location is specified with
`set_source_location()` or the source location is cleared with
`clear_source_location()`. In the later case, subsequent IR instruction
will not be linked to any source location. As you can see, this is a
stateful API (mimicking the one in LLVM), so be careful with source
locations set by previous calls. It's probably best to not rely on any
specific state being present at a given point in code.

One topic that deserves some extra attention is *function prologues*. At
the beginning of a function's machine code there are typically a few
instructions for loading argument values into allocas and checking if
there's enough stack space for the function to execute. This *prologue* is
not visible in the source code and LLVM puts a special PROLOGUE END marker
into the line table at the first non-prologue instruction of the function.
In order to find out where the prologue ends, LLVM looks for the first
instruction in the function body that is linked to a source location. So,
when generating prologue instructions we have to make sure that we don't
emit source location information until the 'real' function body begins. For
this reason, source location emission is disabled by default for any new
function being codegened and is only activated after a call to the third
function from the list above, `start_emitting_source_locations()`. This
function should be called right before regularly starting to codegen the
top-level block of the given function.

There is one exception to the above rule: `llvm.dbg.declare` instruction
must be linked to the source location of the variable being declared. For
function parameters these `llvm.dbg.declare` instructions typically occur
in the middle of the prologue, however, they are ignored by LLVM's prologue
detection. The `create_argument_metadata()` and related functions take care
of linking the `llvm.dbg.declare` instructions to the correct source
locations even while source location emission is still disabled, so there
is no need to do anything special with source location handling here.

## Unique Type Identification

In order for link-time optimization to work properly, LLVM needs a unique
type identifier that tells it across compilation units which types are the
same as others. This type identifier is created by
`TypeMap::get_unique_type_id_of_type()` using the following algorithm:

1. Primitive types have their name as ID

2. Structs, enums and traits have a multipart identifier

1. The first part is the SVH (strict version hash) of the crate they
were originally defined in

2. The second part is the ast::NodeId of the definition in their
original crate

3. The final part is a concatenation of the type IDs of their concrete
type arguments if they are generic types.

3. Tuple-, pointer-, and function types are structurally identified, which
means that they are equivalent if their component types are equivalent
(i.e., `(i32, i32)` is the same regardless in which crate it is used).

This algorithm also provides a stable ID for types that are defined in one
crate but instantiated from metadata within another crate. We just have to
take care to always map crate and `NodeId`s back to the original crate
context.

As a side-effect these unique type IDs also help to solve a problem arising
from lifetime parameters. Since lifetime parameters are completely omitted
in debuginfo, more than one `Ty` instance may map to the same debuginfo
type metadata, that is, some struct `Struct<'a>` may have N instantiations
with different concrete substitutions for `'a`, and thus there will be N
`Ty` instances for the type `Struct<'a>` even though it is not generic
otherwise. Unfortunately this means that we cannot use `ty::type_id()` as
cheap identifier for type metadata -- we have done this in the past, but it
led to unnecessary metadata duplication in the best case and LLVM
assertions in the worst. However, the unique type ID as described above
*can* be used as identifier. Since it is comparatively expensive to
construct, though, `ty::type_id()` is still used additionally as an
optimization for cases where the exact same type has been seen before
(which is most of the time).
179 changes: 0 additions & 179 deletions compiler/rustc_codegen_llvm/src/debuginfo/doc.rs

This file was deleted.

3 changes: 1 addition & 2 deletions compiler/rustc_codegen_llvm/src/debuginfo/mod.rs
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
// See doc.rs for documentation.
mod doc;
#![doc = include_str!("doc.md")]

use rustc_codegen_ssa::mir::debuginfo::VariableKind::*;

Expand Down
1 change: 1 addition & 0 deletions compiler/rustc_codegen_llvm/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
#![feature(bool_to_option)]
#![feature(const_cstr_unchecked)]
#![feature(crate_visibility_modifier)]
#![feature(extended_key_value_attributes)]
#![feature(extern_types)]
#![feature(in_band_lifetimes)]
#![feature(nll)]
Expand Down
4 changes: 2 additions & 2 deletions compiler/rustc_resolve/src/imports.rs
Original file line number Diff line number Diff line change
Expand Up @@ -955,14 +955,14 @@ impl<'a, 'b> ImportResolver<'a, 'b> {
}
return None;
}
PathResult::NonModule(path_res) if path_res.base_res() == Res::Err => {
PathResult::NonModule(_) => {
if no_ambiguity {
assert!(import.imported_module.get().is_none());
}
// The error was already reported earlier.
return None;
}
PathResult::Indeterminate | PathResult::NonModule(..) => unreachable!(),
PathResult::Indeterminate => unreachable!(),
};

let (ident, target, source_bindings, target_bindings, type_ns_only) = match import.kind {
Expand Down
Loading