Fix NOBITS sections inflating flash image and RAM accounting

[AkshathaUdayashankar]

Description:

elf2tab currently filters segments based solely on FileSiz and PhysAddr, with no awareness of ELF section types. This causes two problems when linkers produce segments with nonzero FileSiz for NOBITS (.stack, .bss) sections:

1. Flash bloat: NOBITS data (zeros) is embedded in the TBF image
2. RAM double-counting: minimum_ram_size includes NOBITS via p_memsz and again via stack_len

This occurs on platforms where RAM < FLASH in the address space (e.g., x86). LLD 20+ merges NOBITS and PROGBITS sections into a single PT_LOAD segment when both use AT > FLASH in the linker script, materializing the NOBITS content as zeros with nonzero FileSiz.

Changes:

• Skip segments containing only NOBITS sections, even if FileSiz > 0
• Trim leading/trailing NOBITS from mixed NOBITS+PROGBITS segments
• Collapse the LMA gap left by trimmed NOBITS to prevent inter-segment padding from re-embedding the removed data
• Use PROGBITS section sizes instead of p_memsz for RAM accounting to prevent double-counting with stack_len

Impact on existing platforms:

None. On ARM/RISC-V where NOBITS segments already have FileSiz == 0, the new code does not trigger

[bradjc]

Cool. Linkers are...interesting.

Can you share something like readelf -lS <elf> so we have an example of what requires this?

I'm a little confused why the linker is able to combine sections like stack into segments with data that actually needs to be loaded, but, at the end of the day elf2tab will handle whatever it needs to handle.

[AkshathaUdayashankar]

Cool. Linkers are...interesting.

Can you share something like readelf -lS <elf> so we have an example of what requires this?

I'm a little confused why the linker is able to combine sections like stack into segments with data that actually needs to be loaded, but, at the end of the day elf2tab will handle whatever it needs to handle.

Here's the readelf -lS output from a Rust usermode app built with LLD for an x86 (i386) Tock platform:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .start            PROGBITS        0006c060 001060 0000a8 00  AX  0   0  1
  [ 2] .text             PROGBITS        0006c108 001108 007d2d 00  AX  0   0  1
  [ 3] .rodata           PROGBITS        00073e38 008e38 002610 00 AMS  0   0  4
  [13] .stack            NOBITS          00010000 00c000 009000 00  WA  0   0  1
  [14] .data             PROGBITS        00019000 015000 000064 00  WA  0   0  4
  [15] .bss              NOBITS          00019064 015064 0000d4 00  WA  0   0  4

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001060 0x0006c060 0x0006c060 0x07dd5 0x07dd5 R E 0x1000
  LOAD           0x008e38 0x00073e38 0x00073e38 0x02619 0x02619 R   0x1000
  LOAD           0x00c000 0x00010000 0x00076451 0x09064 0x09138 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0

 Section to Segment mapping:
  Segment Sections...
   00     .start .text
   01     .rodata ...
   02     .stack .data .bss
   03

(Some defmt metadata sections in segment 01 omitted for readability.)

The key issue is segment 02: LLD merges .stack (NOBITS, 0x9000 = 36 KiB), .data (PROGBITS, 0x64 = 100 bytes), and .bss (NOBITS, 0xD4) into a single PT_LOAD with FileSiz = 0x9064. That's 0x9000 + 0x64 — the NOBITS .stack is materialized as 36 KiB of zeros in the file.

On our platform, RAM sits below FLASH in the address space (RAM at 0x10000, FLASH at 0x6c000). The linker script uses AT > FLASH to assign load addresses for initialized data. LLD sees the contiguous LMA range and coalesces the NOBITS and PROGBITS sections into one segment, giving the NOBITS content a nonzero FileSiz.

On ARM/RISC-V this doesn't happen because NOBITS segments already get FileSiz == 0 — the new code in this PR only triggers when it detects nonzero FileSiz on NOBITS sections.

[bradjc]

Thanks for the readelf output. I can't reproduce this with arm/riscv (the linker still puts the .stack section as its own segment even if I make it > SRAM AT > FLASH, but, I can see the benefit.

I have a couple questions about the code, but this generally looks good.

[bradjc]

Suggested change

	/// Trim a segment to exclude leading and trailing NOBITS sections.
	///
	/// Some linkers may merge NOBITS sections (.stack, .bss) with PROGBITS sections
	/// (.data) into a single PT_LOAD segment when they share the same load address
	/// region (e.g., via `AT > FLASH` in the linker script). This causes the
	/// segment's FileSiz to include zero bytes for the NOBITS regions, wasting
	/// flash space when elf2tab copies the segment into the TBF.
	///
	/// This function finds the file offset range covered by PROGBITS sections
	/// within the segment and adjusts `p_offset`, `p_paddr`, `p_vaddr`, `p_filesz`,
	/// and `p_memsz` so the segment covers only that range. Leading NOBITS bytes
	/// (e.g., `.stack` before `.data`) and trailing NOBITS bytes (e.g., `.bss`
	/// after `.data`) are excluded.
	///
	/// Note: `p_paddr` is advanced by the same amount as `p_offset`. The caller
	/// is responsible for collapsing the resulting LMA gap (between this segment
	/// and the previous one) to prevent inter-segment padding from reintroducing
	/// the trimmed NOBITS space.
	/// Trim a segment to exclude leading and trailing NOBITS sections.
	///
	/// Some linkers may merge NOBITS sections (.stack, .bss) with PROGBITS sections
	/// (.data) into a single PT_LOAD segment when they share the same load address
	/// region (e.g., via `AT > FLASH` in the linker script). This causes the
	/// segment's FileSiz to include padding bytes (0x00s) for the NOBITS regions, wasting
	/// flash space when elf2tab copies the segment into the TBF.
	///
	/// This function finds the file offset range covered by PROGBITS sections
	/// within the segment and adjusts `p_offset`, `p_paddr`, `p_vaddr`, `p_filesz`,
	/// and `p_memsz` so the segment covers only that range. Leading NOBITS bytes
	/// (e.g., `.stack` before `.data`) and trailing NOBITS bytes (e.g., `.bss`
	/// after `.data`) are excluded.
	///
	/// Note: `p_paddr` is advanced by the same amount as `p_offset`. The caller
	/// is responsible for collapsing the resulting LMA gap (between this segment
	/// and the previous one) to prevent inter-segment padding from reintroducing
	/// the trimmed NOBITS space.

[AkshathaUdayashankar]

Good call — updated to "padding bytes (0x00s)."

[bradjc]

Is this not the same check as right about (if segment.p_filesz == 0 continue)?

If everything is NOBITS, then filesz must be 0, right?

[AkshathaUdayashankar]

You're right for every case we can currently reproduce. The example segment contains .data (PROGBITS), so this check passes through and trim_nobits_from_segment does the work; afterward p_filesz is nonzero so the p_filesz == 0 guard is also a no-op there. The only case where this check isn't redundant is a segment that is entirely NOBITS yet still has FileSiz > 0 - there, trim_nobits_from_segment finds no PROGBITS, returns early leaving p_filesz at its original nonzero value, so the post-trim p_filesz == 0 guard wouldn't catch it either. I don't have a concrete ELF that produces that (every repro has .data merged in), so unless you know of a linker that emits a standalone .stack with nonzero FileSiz, I'll drop this check and rely on the p_filesz == 0 guard. Preference?

[bradjc]

What does this if block do? It seems like shifting back to effectively remove the trimmed section shouldn't depend on the previous segment.

[AkshathaUdayashankar]

Agreed it was obfuscated. The arithmetic reduces to just restoring the pre-trim LMA, so I've simplified it to [if p_paddr > paddr_before_trim { p_paddr = max(paddr_before_trim, prev_end); (verified byte-identical output). On the prev_end dependence: it's a defensive clamp so the restored LMA can't overlap the previous segment — which may itself have been shifted by the flash-address truncation a few lines down. It doesn't trigger in normal non-overlapping layouts, but since that flash-truncation can move p_paddr, I'd rather keep the clamp than assert it's impossible to overlap. Open to dropping it if you'd prefer a debug_assert! instead.