| 22 Apr 2025 |
 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 |
| rosssmyth | With a patch that can be applied that should fix it | 22:50:50 |
| 23 Apr 2025 |
| dramforever | In reply to @rosssmyth:matrix.org
Cause an embedded toolchain that only works for a specific architecture is kind of silly unfortunately, this is how nixpkgs gcc works | 00:02:52 |
| dramforever | the doesn't support thumb part shouldn't be happening though, that one i should take a look | 00:13:32 |
| dramforever | ... are you sure pkgsCross.arm-embedded.stdenv.cc ever worked for armv6-m? | 01:04:52 |
| dramforever | i'm throwing in the towel for now i have no idea how the arm embedded stuff works | 01:13:03 |
| dramforever | does -march=armv6-m and -mcpu=cortex-m0 even work? | 01:41:18 |
 wucke13 | @dramforever:matrix.org: you can build a GCC for a tailored target, if that helps. Takes half an hour, but the Nix infra is there | 08:42:25 |
| wucke13 | If you take look at
https://github.com/NixOS/nixpkgs/blob/master/lib/systems/examples.nix
You can see that you can specify quite detailed what your target system is like. This information is passed to the GCC build for your stdenv, so even obscure targets can be built like this.
Sometimes you need some extra flags for gcc's build, these are passed via the gcc attr:
https://github.com/NixOS/nixpkgs/blob/7636fe33eae59738f5cdace9d257fb3c727a9898/lib/systems/examples.nix#L227
Once you have a sufficient target description, you can compile it all together into a nix-shell to get the toolchain, for example like this:
https://www.linkedin.com/safety/go?url=https%3A%2F%2Fgist.github.com%2Fwucke13%2F123536af7cfdab7083a2173a064489d2
| 08:53:36 |
| wucke13 | * If you take look at
https://github.com/NixOS/nixpkgs/blob/master/lib/systems/examples.nix
You can see that you can specify quite detailed what your target system is like. This information is passed to the GCC build for your stdenv, so even obscure targets can be built like this.
Sometimes you need some extra flags for gcc's build, these are passed via the gcc attr:
https://github.com/NixOS/nixpkgs/blob/7636fe33eae59738f5cdace9d257fb3c727a9898/lib/systems/examples.nix#L227
Once you have a sufficient target description, you can compile it all together into a nix-shell to get the toolchain, for example like this:
https://gist.github.com/wucke13/123536af7cfdab7083a2173a064489d2 | 08:54:25 |
|  tomas joined the room. | 09:22:41 |
| rosssmyth | It doesn't have to. Multilib exists. | 14:12:23 |
| rosssmyth | Taking a look at the disassembly, no it does not. Because the libc functions are all arm. | 14:12:50 |
| rosssmyth | I never flashed the firmware produced by nix so I never checked | 14:13:11 |
| rosssmyth | That's how I always pass the flags, though the latter is not really needed. | 14:13:34 |
