Nix Cross Compiling - Public Room Timeline

	Nix Cross Compiling	582 Members
		127 Servers

Load older messages

Sender	Message	Time
21 Apr 2025
	9lore joined the room.	15:18:56
rosssmyth	I have a job that runs my builds against latest unstable each weekend, and this weekend the bump from GCC 14.2.1 20241116 to GCC 14.2.1 20250322 has changed something with relocations as I now get a bunch of `dangerous relocation: unsupported relocation`. Mainly because relocations are not supported on the target I used (arm-embedded, armv6-m), but I pass in `hardeningDisable = [ "all" ];`. I expected something to break due to the bump based upon that issue about GCC breakage, but not this. Anyone have any ideas what may have changed?	16:42:03
Tristan Ross	In reply to @rosssmyth:matrix.org I have a job that runs my builds against latest unstable each weekend, and this weekend the bump from GCC 14.2.1 20241116 to GCC 14.2.1 20250322 has changed something with relocations as I now get a bunch of `dangerous relocation: unsupported relocation`. Mainly because relocations are not supported on the target I used (arm-embedded, armv6-m), but I pass in `hardeningDisable = [ "all" ];`. I expected something to break due to the bump based upon that issue about GCC breakage, but not this. Anyone have any ideas what may have changed? What derivation broke?	17:17:44
Tristan Ross	Do you have an easy reproducer?	17:17:58
rosssmyth	So far I have not been able to make one. All of the unsupported relocations are from libc.a. So functions like memset, memcpy, and such. So they all look something like this `/nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/7d1fw0l1akklgigbf3kwah5as1bwic1q-arm-none-eabi-gcc-14.2.1.20250322/lib/gcc/arm-none-eabi/14.2.1/libgcc.a(_divsi3.o)(__aeabi_idiv): Unknown destination type (ARM/Thumb) in /build/ccdF1k4g.ltrans0.ltrans.o > /build/source/build/../Firmware.cydsn/main.c:285:(.text.main+0x8a): dangerous relocation: unsupported relocation` I'll mess around some more this afternoon to see if I can get a minimal reproducer.	18:02:38
rosssmyth	* So far I have not been able to make one. All of the unsupported relocations are from libc.a. So functions like memset, memcpy, and such. So they all look something like this `> /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/7d1fw0l1akklgigbf3kwah5as1bwic1q-arm-none-eabi-gcc-14.2.1.20250322/lib/gcc/arm-none-eabi/14.2.1/libgcc.a(_divsi3.o)(__aeabi_idiv): Unknown destination type (ARM/Thumb) in /build/ccdF1k4g.ltrans0.ltrans.o > /build/source/build/../Firmware.cydsn/main.c:285:(.text.main+0x8a): dangerous relocation: unsupported relocation` I'll mess around some more this afternoon to see if I can get a minimal reproducer.	18:02:51
trofi	`ltrans` suggests these are LTO builds.	21:30:03
trofi	Do you have a reproducer? Chances are `ld` did not have a correct linker plugin present.	21:30:23
trofi	* Chances are `ld` did not have a correct linker plugin present.	21:30:46
rosssmyth	Disabling LTO results in less errors. But the build also fails earlier in the build process. `/nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-me> /build/source/build/../Firmware.cydsn/main.c:118:(.text.main+0x46): dangerous relocation: unsupported relocation`	21:41:58
rosssmyth	* Disabling LTO results in less errors. But the build also fails earlier in the build process. > /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-memset.o)(memset): Unknown destination type (ARM/Thumb) in Firmware.cydsn/out.elf.p/main.c.o > Firmware.cydsn/out.elf.p/main.c.o: in function `main': > /build/source/build/../Firmware.cydsn/main.c:242:(.text.main+0x4e): dangerous relocation: unsupported relocation	21:46:00
rosssmyth	* Disabling LTO removes the references to ltrans, but the same errors result. > /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-memset.o)(memset): Unknown destination type (ARM/Thumb) in Firmware.cydsn/out.elf.p/main.c.o > Firmware.cydsn/out.elf.p/main.c.o: in function `main': > /build/source/build/../Firmware.cydsn/main.c:242:(.text.main+0x4e): dangerous relocation: unsupported relocation	21:46:47
22 Apr 2025
trofi	Aha. Can you have a look what relocation is that? `arm-none-eabi-objdump -dr` should have an entry around `.text.main+0x4e`	04:56:34
rosssmyth	`4e: f7ff fffe bl 0 <memset> 4e: R_ARM_THM_CALL memset`	13:20:19
rosssmyth	Redacted or Malformed Event	13:20:54
rosssmyth	* `0000004e R_ARM_THM_CALL memset`	13:22:31
dramforever	i think i figured out a possible cause. your code might be defining `memset` in assembly, but did not specify the symbol type as a function. therefore, the linker is refusing to emit a call to it because some paranoia about mixing arm and thumb functions.	13:51:19
dramforever	if that's the case, you need to use `.type memset, %function` in your assembly code, and possibly all other functions as well	13:51:42
dramforever	this is a new check added in binutils 2.44 https://github.com/bminor/binutils-gdb/commit/31ed3a9d691493486f6e32357d89a55229dbdc0a#diff-9db1c8e03c72939d28438bba610afca27de21c37dda3d09639a8b531a5610902R10508	13:55:20
dramforever	this should reproduce the "issue" $ cat thm.s bl nothing $ cat nothing.s .global nothing nothing: $ arm-none-eabi-gcc -march=armv6-m -o thm thm.s nothing.s /nix/store/[...]-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/[...]-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/crt0.o: in function `_mainCRTStartup': /build/newlib-4.5.0.20241231/arm-none-eabi/libgloss/../.././libgloss/arm/crt0.S:546:(.text+0x10c): undefined reference to `main' /nix/store/[...]-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /tmp/cceLKLqP.o(nothing): Unknown destination type (ARM/Thumb) in /tmp/ccAnIzhk.o /tmp/ccAnIzhk.o:(.text+0x0): dangerous relocation: unsupported relocation [...]	13:58:21
dramforever	mostly unrelatedly, but the worst part about trying to debug this issue is element defaulted to not line wrapping code	14:04:10
rosssmyth	That's interesting. I do not define them in asm, I just use the newlib(-nano) provided ones. I just checked and it seems they do use the correct type for their asm defined functions.	14:17:37
dramforever	In reply to @rosssmyth:matrix.org That's interesting. I do not define them in asm, I just use the newlib(-nano) provided ones. I just checked and it seems they do use the correct type for their asm defined functions. are you using `pkgsCross.arm-embedded`? in that case the nanolib is compiled for arm and would not work for armv6-m	14:28:08
dramforever	you might need to write your own `crossSystem` while importing nixpkgs	14:36:35
rosssmyth	I tried that well earlier and it did not work with the same error	20:52:34
rosssmyth	* I tried that as well earlier and it did not work with the same error	20:52:40
rosssmyth	I believe I have found the issue. While narrowing down to a minimal reproducer, it seems that passing `-mthumb -mcpu=cortex-m0 -march=armv6-m` with the cross-file, which should just be redundant with the armv6m toolchain, somehow messes up linking. Removing the cross file results in it compiling with the armv6m toolchain. But if the arm-embedded toolchain isn't thumb compatible, then what needs to be done to get multilib working?	22:38:59
rosssmyth	Cause an embedded toolchain that only works for a specific architecture is kind of silly	22:39:40
rosssmyth	Especially if it doesn't support thumb. And I would prefer not to spend 30 minutes building GCC in github actions every time CI runs	22:40:15
rosssmyth	For anyone curious, here's a reproducer https://github.com/RossSmyth/armRepro	22:50:34

Show newer messages

Back to Room ListRoom Version: 6