Claude review: dyndbg: fix NULL ptr on i386 due to section alignment

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Commit message quality:** Good. Clearly explains the root cause (28-byte `__dyndbg_classes` structs on i386 causing misalignment of following `__dyndbg` section) and the three-pronged fix.

**Review of the changes:**

1. **ALIGN(8) added to BOUNDED_SECTION macros** (lines 492, 498 of the diff):
```c
#define BOUNDED_SECTION_PRE_LABEL(_sec_, _label_, _BEGIN_, _END_)	\
	. = ALIGN(8);							\
	_BEGIN_##_label_ = .;						\
```
This is a reasonable belt-and-suspenders approach. However, this is a **broadly impactful change** — `BOUNDED_SECTION_PRE_LABEL` and `BOUNDED_SECTION_POST_LABEL` are used by many sections beyond dyndbg (e.g., `__bug_table`, jump tables, etc.). Adding ALIGN(8) to *all* bounded sections to fix a dyndbg-specific issue is heavy-handed. It may introduce unnecessary padding in sections that have smaller natural alignment requirements. The commit message acknowledges this for ORC but doesn't discuss the impact on other users of the macro.

   **Concern:** Has the impact on vmlinux size been measured across architectures? Adding ALIGN(8) padding before every bounded section could bloat the binary. The arch maintainers (especially Arnd Bergmann, who is CC'd) should weigh in.

2. **Section reordering** (lines 506-508):
```c
	BOUNDED_SECTION_BY(__dyndbg, ___dyndbg)				\
	BOUNDED_SECTION_BY(__dyndbg_classes, ___dyndbg_classes)		\
```
Moving `__dyndbg` before `__dyndbg_classes` so it sits directly after the existing `ALIGN(8)` is the minimal correct fix. This alone would solve the immediate problem without the broader macro change.

3. **ORC unwinder de-macroification** (lines 516-533):
```c
	__start_orc_header = .;					\
	KEEP(*(.orc_header))					\
	__stop_orc_header = .;					\
```
Manually expanding the macro for ORC sections to avoid the new ALIGN(8) is correct — ORC has ALIGN(4) and ALIGN(2) requirements, and `scripts/sorttable.c` cannot tolerate extra padding. However, this creates a maintenance concern: these three sections now duplicate what `BOUNDED_SECTION_BY` would generate (minus the alignment). If `BOUNDED_SECTION_BY` changes semantics in the future, ORC won't track those changes.

   **Suggestion:** Consider adding a comment near the ORC sections explaining *why* they don't use `BOUNDED_SECTION_BY`, so future developers don't "helpfully" convert them back.

**Nit:** The commit says "Closes:" with a lore link, which is good for tracking.

**Verdict:** The fix works but the approach of modifying a global macro is concerning. The section reordering alone (change #2) fixes the immediate issue. The ALIGN(8) in the macro (change #1) is defensive but has non-trivial blast radius. Would prefer an ack from the linker-script/arch maintainers before merging.

---

---
Generated by Claude Code Patch Reviewer