aboutsummaryrefslogtreecommitdiff
path: root/src/link/MachO/Atom.zig
diff options
context:
space:
mode:
authormlugg <mlugg@mlugg.co.uk>2024-07-28 17:09:14 +0100
committermlugg <mlugg@mlugg.co.uk>2024-08-11 07:29:41 +0100
commit548a087fafeda5b07d2237d5137906b8d07da699 (patch)
tree69135f129b84ab5b65f443d0a52899b232696e2b /src/link/MachO/Atom.zig
parent531cd177e89c1edfcd2e52f74f220eb186a25f78 (diff)
downloadzig-548a087fafeda5b07d2237d5137906b8d07da699.tar.gz
zig-548a087fafeda5b07d2237d5137906b8d07da699.zip
compiler: split Decl into Nav and Cau
The type `Zcu.Decl` in the compiler is problematic: over time it has gained many responsibilities. Every source declaration, container type, generic instantiation, and `@extern` has a `Decl`. The functions of these `Decl`s are in some cases entirely disjoint. After careful analysis, I determined that the two main responsibilities of `Decl` are as follows: * A `Decl` acts as the "subject" of semantic analysis at comptime. A single unit of analysis is either a runtime function body, or a `Decl`. It registers incremental dependencies, tracks analysis errors, etc. * A `Decl` acts as a "global variable": a pointer to it is consistent, and it may be lowered to a specific symbol by the codegen backend. This commit eliminates `Decl` and introduces new types to model these responsibilities: `Cau` (Comptime Analysis Unit) and `Nav` (Named Addressable Value). Every source declaration, and every container type requiring resolution (so *not* including `opaque`), has a `Cau`. For a source declaration, this `Cau` performs the resolution of its value. (When #131 is implemented, it is unsolved whether type and value resolution will share a `Cau` or have two distinct `Cau`s.) For a type, this `Cau` is the context in which type resolution occurs. Every non-`comptime` source declaration, every generic instantiation, and every distinct `extern` has a `Nav`. These are sent to codegen/link: the backends by definition do not care about `Cau`s. This commit has some minor technically-breaking changes surrounding `usingnamespace`. I don't think they'll impact anyone, since the changes are fixes around semantics which were previously inconsistent (the behavior changed depending on hashmap iteration order!). Aside from that, this changeset has no significant user-facing changes. Instead, it is an internal refactor which makes it easier to correctly model the responsibilities of different objects, particularly regarding incremental compilation. The performance impact should be negligible, but I will take measurements before merging this work into `master`. Co-authored-by: Jacob Young <jacobly0@users.noreply.github.com> Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Diffstat (limited to 'src/link/MachO/Atom.zig')
-rw-r--r--src/link/MachO/Atom.zig20
1 files changed, 20 insertions, 0 deletions
diff --git a/src/link/MachO/Atom.zig b/src/link/MachO/Atom.zig
index 8a47a30264..d0e0fe377d 100644
--- a/src/link/MachO/Atom.zig
+++ b/src/link/MachO/Atom.zig
@@ -992,6 +992,8 @@ pub fn writeRelocs(self: Atom, macho_file: *MachO, code: []u8, buffer: []macho.r
const tracy = trace(@src());
defer tracy.end();
+ relocs_log.debug("{x}: {s}", .{ self.getAddress(macho_file), self.getName(macho_file) });
+
const cpu_arch = macho_file.getTarget().cpu.arch;
const relocs = self.getRelocs(macho_file);
@@ -1015,6 +1017,24 @@ pub fn writeRelocs(self: Atom, macho_file: *MachO, code: []u8, buffer: []macho.r
addend += target;
}
+ switch (rel.tag) {
+ .local => relocs_log.debug(" {}: [{x} => {d}({s},{s})] + {x}", .{
+ rel.fmtPretty(cpu_arch),
+ r_address,
+ r_symbolnum,
+ macho_file.sections.items(.header)[r_symbolnum - 1].segName(),
+ macho_file.sections.items(.header)[r_symbolnum - 1].sectName(),
+ addend,
+ }),
+ .@"extern" => relocs_log.debug(" {}: [{x} => {d}({s})] + {x}", .{
+ rel.fmtPretty(cpu_arch),
+ r_address,
+ r_symbolnum,
+ rel.getTargetSymbol(self, macho_file).getName(macho_file),
+ addend,
+ }),
+ }
+
switch (cpu_arch) {
.aarch64 => {
if (rel.type == .unsigned) switch (rel.meta.length) {