Feed of "mlugg" https://codeberg.org/mlugg Mon, 14 Sep 2026 20:27:22 +0200 mlugg created pull request ziglang/zig#36827 https://codeberg.org/ziglang/zig/pulls/36827 36827#Zcu: report multi-module errors against correct file# We were incorrectly using the second referencer as the file to report
against, when it was meant to be the file with the ambiguous module. I
somehow didn't notice this when writing the tests and was explicitly
testing the wrong thing!

]]> mlugg 208656875: https://codeberg.org/ziglang/zig/pulls/36827 Sun, 13 Sep 2026 17:08:21 +0200 mlugg closed pull request ziglang/zig#36826 https://codeberg.org/ziglang/zig/pulls/36826#issuecomment-22760620 Zcu: report multi-module errors against correct file mlugg 208655873: https://codeberg.org/ziglang/zig/pulls/36826#issuecomment-22760620 Sun, 13 Sep 2026 17:07:50 +0200 mlugg created pull request ziglang/zig#36826 https://codeberg.org/ziglang/zig/pulls/36826 36826#Zcu: report multi-module errors against correct file# We were incorrectly using the second referencer as the file to report
against, when it was meant to be the file with the ambiguous module. I
somehow didn't notice this when writing the tests and was explicitly
testing the wrong thing!

]]> mlugg 208602118: https://codeberg.org/ziglang/zig/pulls/36826 Sun, 13 Sep 2026 14:51:54 +0200 mlugg closed issue ziglang/zig#36779 https://codeberg.org/ziglang/zig/issues/36779#issuecomment-22647028 Sized enums depend on their values for size query mlugg 207343297: https://codeberg.org/ziglang/zig/issues/36779#issuecomment-22647028 Thu, 10 Sep 2026 23:31:52 +0200 mlugg commented on issue ziglang/zig#36779 https://codeberg.org/ziglang/zig/issues/36779#issuecomment-22647025 Sized enums depend on their values for size query <p dir="auto">Working as intended; the Zig type system is a bit more constrained than theoretically necessary to avoid extremely complicated semantic analysis language rules.</p> Working as intended; the Zig type system is a bit more constrained than theoretically necessary to avoid extremely complicated semantic analysis language rules.

]]> mlugg 207343292: https://codeberg.org/ziglang/zig/issues/36779#issuecomment-22647025 Thu, 10 Sep 2026 23:31:51 +0200 mlugg merged pull request ziglang/zig#36763 https://codeberg.org/ziglang/zig/pulls/36763 Elf2: fix crash when creating copy relocation mlugg 204757039: https://codeberg.org/ziglang/zig/pulls/36763 Sun, 06 Sep 2026 12:15:17 +0200 mlugg pushed to master at ziglang/zig https://codeberg.org/ziglang/zig/commit/07811f47965cf850bfaba3cafdab47408d31853a <a href="https://codeberg.org/ziglang/zig/commit/07811f47965cf850bfaba3cafdab47408d31853a">07811f47965cf850bfaba3cafdab47408d31853a</a> Elf2: fix crash when creating copy relocation 07811f47965cf850bfaba3cafdab47408d31853a Elf2: fix crash when creating copy relocation]]> mlugg 204757027: https://codeberg.org/ziglang/zig/commit/07811f47965cf850bfaba3cafdab47408d31853a Sun, 06 Sep 2026 12:15:15 +0200 mlugg created pull request ziglang/zig#36763 https://codeberg.org/ziglang/zig/pulls/36763 36763#Elf2: fix crash when creating copy relocation# Accidental regression in #36413.
Not sure how I didn't run into this sooner!

]]> mlugg 204337855: https://codeberg.org/ziglang/zig/pulls/36763 Sat, 05 Sep 2026 16:39:40 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22377778 ELF2: Initial bss support <p dir="auto">I did some playing around to figure out how other linkers behave here. Results:</p> I did some playing around to figure out how other linkers behave here. Results:

]]> mlugg 204215707: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22377778 Sat, 05 Sep 2026 11:52:59 +0200 mlugg created pull request ziglang/zig#36751 https://codeberg.org/ziglang/zig/pulls/36751 36751#std.debug.Dwarf: basic support for DW_LNE_ZIG_set_decl# This makes stack traces with -fincremental, um, sort of work:

thread 29999 panic: this is the RIGHT panic
/home/mlugg/panic.zig:15:25: 0x7a1907 in bar (panic.zig)
        1, 2, 3, 123 => @panic("this is the RIGHT panic"),
                        ^
/home/mlugg/panic.zig:7:12: 0x7a138c in foo (panic.zig)
        bar(123);
           ^
/home/mlugg/panic.zig:2:8: 0x7a12fe in main (panic.zig)
    foo(true);
       ^
/home/mlugg/zig/master/lib/std/start.zig:779:64: 0x7a0e3b in callMain (std.zig)

                                                               ^
/home/mlugg/zig/master/lib/std/Target.zig:1651:5: 0x7a0861 in _start (std.zig)
        pub inline fn isSparc(arch: Arch) bool {
    ^
Aborted                    ./panic

The last two frames are clearly incorrect. However, we actually agree
with lldb-zig about those source locations, so it seems like that's a
bug in the compiler's link.Dwarf2 implementation.

]]> mlugg 203687731: https://codeberg.org/ziglang/zig/pulls/36751 Fri, 04 Sep 2026 11:46:35 +0200 mlugg commented on issue ziglang/zig#35791 https://codeberg.org/ziglang/zig/issues/35791#issuecomment-22261675 Debug info support in Elf2 <p dir="auto">While not 100% complete, <a href="https://codeberg.org/ziglang/zig/pulls/36413" class="ref-issue" rel="nofollow">#36413</a> (which should be mergeable soon) is a large chunk of this work. Perhaps most importantly, it implements source location information, so stack traces should be fully functional and stepping through code in a debugger should work (though AIUI printing values in a debugger will not yet be possible until a follow-up PR).</p> While not 100% complete, #36413 (which should be mergeable soon) is a large chunk of this work. Perhaps most importantly, it implements source location information, so stack traces should be fully functional and stepping through code in a debugger should work (though AIUI printing values in a debugger will not yet be possible until a follow-up PR).

]]> mlugg 203229502: https://codeberg.org/ziglang/zig/issues/35791#issuecomment-22261675 Thu, 03 Sep 2026 13:36:56 +0200 mlugg closed issue ziglang/zig#36652 https://codeberg.org/ziglang/zig/issues/36652#issuecomment-22174225 Incremental test `add_decl_namespaced` is flaky for `x86_64-linux-selfhosted` mlugg 202273042: https://codeberg.org/ziglang/zig/issues/36652#issuecomment-22174225 Tue, 01 Sep 2026 21:22:15 +0200 mlugg closed issue ziglang/zig#36654 https://codeberg.org/ziglang/zig/issues/36654#issuecomment-22174222 Incremental test `add_decl` is flaky for `x86_64-linux-selfhosted` mlugg 202272826: https://codeberg.org/ziglang/zig/issues/36654#issuecomment-22174222 Tue, 01 Sep 2026 21:22:14 +0200 mlugg closed issue ziglang/zig#36653 https://codeberg.org/ziglang/zig/issues/36653#issuecomment-22174219 Incremental test `change_enum_tag_type` is flaky for `wasm32-wasi-selfhosted` mlugg 202272451: https://codeberg.org/ziglang/zig/issues/36653#issuecomment-22174219 Tue, 01 Sep 2026 21:22:13 +0200 mlugg closed issue ziglang/zig#36650 https://codeberg.org/ziglang/zig/issues/36650#issuecomment-22174216 Incremental test `add_decl_namespaced` is flaky for `wasm32-wasi-selfhosted` mlugg 202270651: https://codeberg.org/ziglang/zig/issues/36650#issuecomment-22174216 Tue, 01 Sep 2026 21:22:12 +0200 mlugg merged pull request ziglang/zig#36714 https://codeberg.org/ziglang/zig/pulls/36714 incr-check: update timestamp on each update mlugg 202270366: https://codeberg.org/ziglang/zig/pulls/36714 Tue, 01 Sep 2026 21:22:10 +0200 mlugg pushed to master at ziglang/zig https://codeberg.org/ziglang/zig/commit/79837d51123460e4f0a04ba523d01b10f7c314cd <a href="https://codeberg.org/ziglang/zig/commit/79837d51123460e4f0a04ba523d01b10f7c314cd">79837d51123460e4f0a04ba523d01b10f7c314cd</a> incr-check: update timestamp on each update 79837d51123460e4f0a04ba523d01b10f7c314cd incr-check: update timestamp on each update]]> mlugg 202270360: https://codeberg.org/ziglang/zig/commit/79837d51123460e4f0a04ba523d01b10f7c314cd Tue, 01 Sep 2026 21:22:10 +0200 mlugg pushed to master at ziglang/zig https://codeberg.org/ziglang/zig/commit/c961124d93a47e9ae317b2e057cf0fe5118303e3 <a href="https://codeberg.org/ziglang/zig/commit/c961124d93a47e9ae317b2e057cf0fe5118303e3">c961124d93a47e9ae317b2e057cf0fe5118303e3</a> Type: fix layout resolution assertion in <code class="inline-code-block">classify</code> c961124d93a47e9ae317b2e057cf0fe5118303e3 Type: fix layout resolution assertion in classify]]> mlugg 202267639: https://codeberg.org/ziglang/zig/commit/c961124d93a47e9ae317b2e057cf0fe5118303e3 Tue, 01 Sep 2026 21:17:26 +0200 mlugg merged pull request ziglang/zig#36711 https://codeberg.org/ziglang/zig/pulls/36711 Type: fix layout resolution assertion in `classify` mlugg 202266796: https://codeberg.org/ziglang/zig/pulls/36711 Tue, 01 Sep 2026 21:17:08 +0200 mlugg suggested changes for ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22122907 ELF2: Initial bss support <p dir="auto">Looking good! I reviewed this in full this time around. Most of my comments should be pretty easy to resolve.</p> Looking good! I reviewed this in full this time around. Most of my comments should be pretty easy to resolve.

]]> mlugg 201985660: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22122907 Tue, 01 Sep 2026 11:49:15 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118626 ELF2: Initial bss support <p dir="auto">Can we pull the <code>childrenMoved</code> call and the conditional <code>updateNobitsAddress</code> call into a new function <code>loadSegmentChildrenMoved</code> or something? Then we can call it in the earlier code path too (lines 8774--8788). I prefer not to have this non-trivial block of logic be duplicated.</p> Can we pull the childrenMoved call and the conditional updateNobitsAddress call into a new function loadSegmentChildrenMoved or something? Then we can call it in the earlier code path too (lines 8774--8788). I prefer not to have this non-trivial block of logic be duplicated.

]]> mlugg 201984916: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118626 Tue, 01 Sep 2026 11:49:14 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118305 ELF2: Initial bss support <p dir="auto">The stores to <code>memsz</code> and <code>type</code> should be here too; you moved them to the bottom of the function in the first version of this patch, but that&#39;s no longer necessary.</p> The stores to memsz and type should be here too; you moved them to the bottom of the function in the first version of this patch, but that's no longer necessary.

]]> mlugg 201984172: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118305 Tue, 01 Sep 2026 11:49:13 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118176 ELF2: Initial bss support <p dir="auto">Isn&#39;t that update literally just the ~9 lines of O(1) work at the start and end of <code>updateNobitsAddress</code>? That&#39;s not even really any more code than this <code>updateNobitsAddress</code> call! Even if it was, we clearly shouldn&#39;t do an unnecessary O(N) loop over <em>all tbss symbols</em> just for a single O(1) operation.</p> Isn't that update literally just the ~9 lines of O(1) work at the start and end of updateNobitsAddress? That's not even really any more code than this updateNobitsAddress call! Even if it was, we clearly shouldn't do an unnecessary O(N) loop over all tbss symbols just for a single O(1) operation.

]]> mlugg 201983428: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22118176 Tue, 01 Sep 2026 11:49:12 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22117612 ELF2: Initial bss support <p dir="auto">Hmmm, is it correct to default this to 0? i.e. is it guaranteed that the section&#39;s address will be assigned at some point after this function is called? At the very least that sounds like an additional requirement for the caller which should be documented. You could probably just add doc comment on the <code>opts.type</code> field which says something like:</p> <pre class="code-block"><code class="chroma language-zig display"><span class="cs">/// If this is `.NOBITS`, then the section&#39;s address is initialized to 0, and it is the caller&#39;s</span><span class="w"> </span><span class="cs">/// responsibility to populate it.</span><span class="w"> </span></code></pre> Hmmm, is it correct to default this to 0? i.e. is it guaranteed that the section's address will be assigned at some point after this function is called? At the very least that sounds like an additional requirement for the caller which should be documented. You could probably just add doc comment on the opts.type field which says something like:

/// If this is `.NOBITS`, then the section's address is initialized to 0, and it is the caller's
/// responsibility to populate it.
]]> mlugg 201982684: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22117612 Tue, 01 Sep 2026 11:49:11 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22100836 ELF2: Initial bss support <p dir="auto">Actually creating <code>SHT_NOBITS</code> sections here seems like a bad idea, because they won&#39;t work at all, at least not yet---the address allocation logic later on is specific to the known <code>.bss</code> and <code>.tbss</code> sections. I think it&#39;d be best to add a new error to this function&#39;s error set, <code>error.UnsupportedNobitsSection</code>, which we can return in this case. <code>loadObject</code> can handle that error with a message something like this:</p> <pre class="code-block"><code class="chroma language-zig display"><span class="k">error</span><span class="p">.</span><span class="n">UnsupportedNobitsSection</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"> </span><span class="k">return</span><span class="w"> </span><span class="n">diags</span><span class="p">.</span><span class="nf">failParse</span><span class="p">(</span><span class="w"> </span><span class="w"> </span><span class="n">path</span><span class="p">,</span><span class="w"> </span><span class="w"> </span><span class="s">&#34;unsupported section type SHT_NOBITS for non-bss section &#39;{s}&#39;&#34;</span><span class="p">,</span><span class="w"> </span><span class="w"> </span><span class="p">.{</span><span class="n">name</span><span class="p">},</span><span class="w"> </span><span class="p">),</span><span class="w"> </span></code></pre> Actually creating SHT_NOBITS sections here seems like a bad idea, because they won't work at all, at least not yet---the address allocation logic later on is specific to the known .bss and .tbss sections. I think it'd be best to add a new error to this function's error set, error.UnsupportedNobitsSection, which we can return in this case. loadObject can handle that error with a message something like this:

error.UnsupportedNobitsSection => return diags.failParse(
    path,
    "unsupported section type SHT_NOBITS for non-bss section '{s}'",
    .{name},
),
]]> mlugg 201981940: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22100836 Tue, 01 Sep 2026 11:49:10 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22099750 ELF2: Initial bss support <p dir="auto">This can just be <code>!opts.has_file_bits</code>, because we never put a <code>NOBITS</code> input section into a <code>PROGBITS</code> output section or vice versa.</p> This can just be !opts.has_file_bits, because we never put a NOBITS input section into a PROGBITS output section or vice versa.

]]> mlugg 201981193: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22099750 Tue, 01 Sep 2026 11:49:09 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22099729 ELF2: Initial bss support <p dir="auto">This change is a no-op because the section doesn&#39;t have a node, right? I wouldn&#39;t have flagged this up, but I noticed you <em>did</em> add <code>.tbss</code> here but did <em>not</em> add <code>.bss</code>. I&#39;m fine with adding them here anyway if you prefer, but let&#39;s be consistent and either add both or add neither.</p> This change is a no-op because the section doesn't have a node, right? I wouldn't have flagged this up, but I noticed you did add .tbss here but did not add .bss. I'm fine with adding them here anyway if you prefer, but let's be consistent and either add both or add neither.

]]> mlugg 201980449: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22099729 Tue, 01 Sep 2026 11:49:08 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22122421 ELF2: Initial bss support <p dir="auto">Hmm, I&#39;m kind of uneasy iterating <em>all globals</em> (of which there are many) just to pick out the <code>.bss</code> ones (of which there are probably very few!), but this isn&#39;t trivial to solve. I might want to do something like change how the symbol linked list (<code>prev_in_node</code>/<code>next_in_node</code>) works so we can use it here... or perhaps we could actually mark these symbols as being in the data/tls <em>segment</em> node? Don&#39;t make any changes for now, let&#39;s figure out all the other stuff first, but I&#39;m leaving this comment here as a note to myself to revisit this before merging.</p> Hmm, I'm kind of uneasy iterating all globals (of which there are many) just to pick out the .bss ones (of which there are probably very few!), but this isn't trivial to solve. I might want to do something like change how the symbol linked list (prev_in_node/next_in_node) works so we can use it here... or perhaps we could actually mark these symbols as being in the data/tls segment node? Don't make any changes for now, let's figure out all the other stuff first, but I'm leaving this comment here as a note to myself to revisit this before merging.

]]> mlugg 201979705: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22122421 Tue, 01 Sep 2026 11:49:07 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22119085 ELF2: Initial bss support <p dir="auto">You should be able to remove this case now, since you aren&#39;t making nodes for the <code>SHT_NOBITS</code> sections.</p> You should be able to remove this case now, since you aren't making nodes for the SHT_NOBITS sections.

]]> mlugg 201978961: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22119085 Tue, 01 Sep 2026 11:49:06 +0200 mlugg commented on pull request ziglang/zig#36699 https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22117507 ELF2: Initial bss support <p dir="auto">Question (which I can find the answer to myself, just writing it here so I remember to!): is this a thing other linkers support? If it is, then we&#39;ll have to detect this case and I guess convert the section into an actual file-backend section. If not, then this error message should be reworded to something like this:</p> <pre class="code-block"><code class="chroma language-text display">cannot apply relocation to SHT_NOBITS section &#39;{s}&#39; </code></pre><p dir="auto">...so that it&#39;s clear it&#39;s not just a missing feature in Elf2!</p> Question (which I can find the answer to myself, just writing it here so I remember to!): is this a thing other linkers support? If it is, then we'll have to detect this case and I guess convert the section into an actual file-backend section. If not, then this error message should be reworded to something like this:

cannot apply relocation to SHT_NOBITS section '{s}'

...so that it's clear it's not just a missing feature in Elf2!

]]> mlugg 201978217: https://codeberg.org/ziglang/zig/pulls/36699#issuecomment-22117507 Tue, 01 Sep 2026 11:49:05 +0200