Fix SECTION UNION alignment depending on piece order

[Rangi42]

Fixes #1881

The one-line fix was found by @vulcandth using OpenAI Codex (in 5 minutes!), prompted with the issue description I had written. Its conclusion:

Root cause was in how rgblink merges SECTION UNION pieces: when a later object contributed a stronger alignment, the linker updated the alignment mask but accidentally kept the old alignment offset (often 0). That made the combined section’s required ALIGN[power, offset] depend on which object file was seen first.
Patched the merge logic to copy alignOfs alongside alignMask when adopting a stronger alignment constraint.

I'm pretty confident this is a correct fix, given that it now makes checkSectUnionCompat clearly symmetrical with checkFragmentCompat. I can add more test cases if we think of any that would cover appropriate new scenarios.

Also confirmed that it builds https://github.com/ariscop/polishedcrystal/tree/audio even with an align 8 now.

[ISSOtm]

Yep, fix looks good, and the refactoring doesn't strike me as incorrect, so all good.

[ISSOtm]

I'm personally not convinced by the use of a LLM here, since the hard work (of narrowing the bug down) had already been performed, and a human would've been able to perform the fix in the same five minutes.

[EDIT: Some friends asked me about this, and I've given a more lengthy analysis of my stance, but wish to reproduce it in a more public place for easier future linking to.]

The intelligence and expertise sought out of us developers lies as much in the “I know what I need, so I'm going to do this” as it does in evaluating whether “this” is adapted or not; delegating the actual code modifications to a third party (be it a LLM or an intern, that changes nothing for you) implies detaching yourself from them, and thus stop evolving your understanding of the code—thus losing your expertise through aging, like a manager.

For context to the above PR and linked issue, Rangi raised the original bug in polishedcrystal to me yesterday, asking for help narrowing it down; I replied “I think the error is in this component¹, here's a sequence of actions we can take to verify that (and thus pare down how much code may be involved and where), huh they are consistent, thus the error must be in another component, 🥱 well let's investigate the rest tomorrow”.

Had we delegated writing the code entirely to a LLM, the codebase would be a black box to us, and thus I would've been unable to provide the above reasoning. At best, I could've thrown the black box at another one, asking a LLM to analyse the codebase and hope that its analysis made sense.

Unless one trains a LLM on a specific codebase, it's never going to gain specific domain knowledge, and thus is far more likely to answer incorrectly², and you'd be none the wiser.

Where it all gets to a head is partial bug fixes: for example, if the LLM had judged that a if (section->alignOfs == 0) section->alignOfs = 87; would be the appropriate fix to the above issue (e.g. in the section-reading code, or in the piece-merging functions, or whatever), then yes that would let polishedcrystal build and would turn the test case green³, but I hope we all agree it wouldn't actually fix the bug.

And, yes, the exact one-liner above is clearly wrong to at least this project's two maintainers; but, increase the complexity of the putative submitted patch a little, or decrease your knowledge of the codebase (such as by the “black-boxing” process I outlined in an earlier paragraph), and judging whether a solution is “truly” appropriate becomes much, much more tricky.

tl;dr: A LLM does not learn from repeated interactions, while delegating the actual work of typing the words and laying out the logic ourselves creates distance from the code (more as a result of losing subconscious / “muscle-memory” engagement) that weakens our very ability to oversee and evaluate the LLM's output. I would parallel this to what I've heard about “learning to type before to hand-write reduces your understanding of language”, and also the more general sentiment that LLM usage amounts to “rolling up the ladder behind us”.

Footnotes

1. RGBASM to be precise, but that's irrelevant to the point being made here. ↩

2. “like a junior”, I would add with a little wince, since juniors are essential because seniors age and move on; what makes a good junior, in my eyes, is entirely their ability to learn and thus turn into a senior. If my understanding of LLMs is correct, they aren't continuously trained, thus being permanent juniors, thereby having all of the downsides and none of the upsides. ↩

3. Assuming that the test case is correct in the first place, but the process of writing it is practically equivalent to narrowing the bug down, and the wrong test case will likely lead to the wrong bug fix, so IMO this entire discussion recursively applies to that. ↩

[Rangi42]

I'm personally not convinced by the use of a LLM here, since the hard work (of narrowing the bug down) had already been performed, and a human would've been able to perform the fix in the same five minutes.

If you mean that you're not convinced it's a correct or complete bug fix, that's what PR review is for anyway -- if/when I'd come across this one-line discrepancy in manual code debugging, I can tell that I'd believe it to be correct, and would have opened this same PR no matter what. So regardless of LLMs, I'm looking for a second pair of eyes to verify that.

Some friends asked me about this, and I've given a more lengthy analysis of my stance [...]

I'm... not going to get into that. 😅 I don't think GitHub Issues is the place for it, and the only reason I mentioned Codex at all was to give vulcandth proper credit, and to avoid claiming/implying that either of us personally read and understood the alignment-related code well enough to have found this. (I know I'd have taken more than five minutes investigating other possibilities before landing on this correct one.) Maybe in future I should just not mention if/how AI was involved, if it just causes unnecessary controversy over a one-line bugfix (and subsequent refactor that's entirely my judgement).

Edit:

Yep, fix looks good, and the refactoring doesn't strike me as incorrect, so all good.

Oh okay, so you are convinced it's a good fix. Then I don't think anything else is relevant, at least not to be discussed in this issue. (I suppose if you want it to be in "a more public place", a GitHub Discussion would also work, if you want to move your stance description to there? Or your blog, if you feel like it's more personal-belief-related than RGBDS-maintenance-related.)