Ticket 23830 - FreeBSD: lld crashes when embedding help.txt via ld/objcopy – replaced with portable .S assembly rule
Summary: FreeBSD: lld crashes when embedding help.txt via ld/objcopy – replaced with p...
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Build System and Packaging (show other tickets)
Version: 25.05.3
Hardware: Other Other
: C - Contributions
Assignee: Tim McMullan
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2025-10-06 21:40 MDT by Rikka Göring
Modified: 2026-02-26 07:05 MST (History)
1 user (show)

See Also:
Site: -Other-
Slinky Site: ---
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
Google sites: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed: 26.05.0rc1
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---


Attachments
add ld emulation on FreeBSD for --format=binary (2.64 KB, patch)
2025-11-07 19:24 MST, Rikka Göring
Details | Diff
t23830 26.05 v1 (122.07 KB, patch)
2026-02-24 11:31 MST, Tim McMullan
Details | Diff

Note You need to log in before you can comment on or make changes to this ticket.
Description Rikka Göring 2025-10-06 21:40:40 MDT
Hi Slurm team,

while upgrading Slurm 25.05 for FreeBSD, I ran into a linker crash when building several utilities (e.g., sacct, scontrol, sinfo, sprio, squeue) that attempt to embed help.txt and usage.txt using:

ld -r -o "$*.bino" -z noexecstack --format=binary ...
objcopy --rename-section .data=.rodata,...

On FreeBSD, this step consistently crashes lld, the system linker.
To resolve this, I implemented a local workaround in the Ports tree that replaces the binary embedding rule with a portable .S assembler snippet compiled by the C compiler, e.g.:

help.o: help.txt
	$(AM_V_GEN){ \
	  echo '	.section .rodata'; \
	  echo '	.globl _binary_help_txt_start'; \
	  echo '	.globl _binary_help_txt_end'; \
	  echo '_binary_help_txt_start:'; \
	  echo '	.incbin "$(abs_srcdir)/help.txt"'; \
	  echo '_binary_help_txt_end:'; \
	  echo '	.byte 0'; \
	} > $@.S
	$(AM_V_at)$(CC) -c -x assembler-with-cpp -o $@ $@.S && rm -f $@.S

This approach preserves the intended embedded data but avoids direct ld/objcopy usage, allowing all affected utilities to build and link cleanly with FreeBSD’s lld.

I plan to prepare a proper upstream patch that updates Makefile.am accordingly (rather than patching Makefile.in) and submit it for review once finalized.
This issue is primarily to document the problem and track an upstreamable solution.

Environment:
- OS: FreeBSD 14.3-RELEASE / 15.0-ALPHA4
- Linker: lld (base system)
- Slurm version: 25.05.x
- Build system: autotools / gmake
- Affected components: utilities embedding help.txt / usage.txt

Impact:
Build failure (linker crash) during Slurm build on FreeBSD when ld --format=binary and objcopy are invoked.

Workaround:
Replaced ld/objcopy embedding with portable .S assembly compiled through $(CC).
Comment 1 Rikka Göring 2025-11-06 23:32:50 MST
Hi everyone,

I just upgraded the FreeBSD Slurm port to version 25.11.0 and noticed that this issue has already been fixed upstream — you were faster than me here!

Apologies for the delay in following up; I’m currently in the middle of my exam phase. Thank you very much for addressing this — it allows me to drop several patch files from the FreeBSD port, meaning Slurm now builds almost entirely unpatched on FreeBSD. That’s a historic milestone!

Marking this issue as RESOLVED (FIXED).

Best regards,
Rikka Göring
Comment 2 Rikka Göring 2025-11-07 01:04:16 MST
Hi everyone,

Reopening this issue — I closed it prematurely. I had part of the FreeBSD workaround still in place, which I overlooked, and removing it brought the problem back.

On FreeBSD 14.3 / 15.0 with lld, the line
ld -r -o "$*.bino" -z noexecstack --format=binary …
still fails unless an explicit emulation is added (e.g. -m elf_amd64 or -m aarch64elf).
Otherwise lld reports “target emulation unknown” and the build stops.

The FreeBSD port fixes this by inserting -m ${_ARCH} wherever --format=binary is used.
Upstream could resolve it by either detecting LD_EMULATION in configure or replacing the embedding logic with a .S + .incbin approach.

Apologies for the confusion earlier, and thanks for your patience!

Best,
Rikka Göring
Comment 3 Rikka Göring 2025-11-07 19:24:34 MST
Created attachment 43578 [details]
add ld emulation on FreeBSD for --format=binary

This patch fixes build failures on FreeBSD caused by lld requiring an explicit emulation flag when invoking
ld --format=binary directly. It adds $(LD_EMULATION) to make_ref.include, detected automatically in configure for FreeBSD architectures.

The change resolves the issue on FreeBSD while having no effect on Linux (tested on Arch Linux).
Patch applies cleanly against current master.
Comment 4 Tim McMullan 2026-02-24 11:31:36 MST
Created attachment 44486 [details]
t23830 26.05 v1

Hey!

I've been doing some looking and testing on this and I think its good to go.  I've uploaded the full version of what would land, like last time just want to make sure I'm not putting words in your mouth!

Thanks!
--Tim
Comment 5 Rikka Göring 2026-02-25 17:40:28 MST
Hi — thanks for looking into this and for regenerating the generated Autotools files (I missed that Slurm also tracks these). The wording looks great, thanks for checking with me first; LGTM. Feel free to merge when ready!
Comment 6 Tim McMullan 2026-02-26 07:05:07 MST
(In reply to Rikka Göring from comment #5)
> Hi — thanks for looking into this and for regenerating the generated
> Autotools files (I missed that Slurm also tracks these). The wording looks
> great, thanks for checking with me first; LGTM. Feel free to merge when
> ready!

No worries on missing the autotools files, I would have regenerated them anyway to make sure it was exactly the same version as the rest of them!

Thanks for confirmation that this was good!  I've merged it in this merge commit https://github.com/SchedMD/slurm/commit/385a72a6c5 and it should be included in 26.05.0!

I'll resolve this now, but feel free to let me know if you have any questions!

Thank you again for your contributions, I really appreciate it!
--Tim