| 23 Apr 2025 |
 rosssmyth | Which is unfortunate because the arm-embedded gcc does state it supports armv6-m. But in reality this is not true. | 14:16:07 |
| rosssmyth | * Which is unfortunate because the arm-embedded gcc does state it supports armv6-m. But in reality this is not true because of libc. | 14:16:18 |
| rosssmyth | Oh yeah I did find another issue where if you use the config armv6m-none-eabi the compiler doesn't actually target armv6-m, it targets arm6kz. To actually target armv6-m you must specify gcc.float-abi = "softfp". | 14:18:06 |
| rosssmyth | * It is required for the assembler to accept the correct asm. | 15:39:50 |
| rosssmyth | Well testing it, even without the cross file it still fails on the real firmware. I give up and am just reverting back to the arm provided binary gcc as I already wasted a day of working messing with this. | 15:41:05 |
 dramforever | In reply to @rosssmyth:matrix.org
It doesn't have to. Multilib exists. multilib does not exist in nixpkgs's stdenv.cc | 16:23:41 |
| dramforever | In reply to @wucke13:matrix.org
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 i've been trying to go all in on the configurification and used gcc.cpu = "cortex-m0". newlib fails to compile | 16:24:28 |
| dramforever | i don't have the logs conveniently available but it's something like "sorry, unimplemented" for a few random functions | 16:25:56 |
| rosssmyth | Then something is messed up with how newlib is being built because I ship firmware that uses those exact flags. | 16:27:16 |
| dramforever | i'm not surprised that arm's gcc is different from what we have in nixpkgs | 16:28:16 |
| dramforever | or newlib | 16:28:23 |
| rosssmyth | arm's gcc is just upstream gcc with some config flags afaik. | 16:28:40 |
| rosssmyth | Download 14.2.rel1-x86_64-arm-none-eabi-manifest.txt | 16:30:29 |
| rosssmyth | that's the manifest | 16:30:34 |
| rosssmyth | * that's the config manifest | 16:31:04 |
| rosssmyth | There should be some sort of solution. The arm-embedded gcc supports multiple arches, the mainly limiter is the libc. Clang has some way of only rebuilding compiler-rt for different targets. Even rebuilding the libc would be acceptable. | 16:33:12 |
| dramforever | i'm not familiar with gcc internals, but i guess we can have some sort of database of "base" gccs | 16:36:47 |
| dramforever | the main difference between gcc and clang in this regard is that one single clang can support all targets | 16:37:03 |
| rosssmyth | Yes, Clang is sane. But right now a clang stdenv can't be built for arm-embedded | 16:39:08 |
| rosssmyth | Redacted or Malformed Event | 16:39:55 |
| rosssmyth | * Yes, Clang is sane. But right now a clang stdenv can't be built for arm-embedded | 16:41:47 |
| dramforever | can you confirm that arm-embedded has ever worked before? | 16:41:52 |
| dramforever | to me it doesn't seem like pkgsCross.arm-embedded.stdenv.cc should successfully build for -mcpu=cortex-m0 | 16:43:12 |
| dramforever | it is effectively an unimplemented case | 16:43:29 |
| dramforever | * it is effectively an unimplemented case in nixpkgs | 16:43:34 |
| rosssmyth | Define "worked" | 16:44:09 |
| dramforever | successfully produce a program for cortex-m0 | 16:44:35 |
| rosssmyth | I showed you how I have done it, and it compiled successfully. I have not flashed any firmware, and inspecting the objdump it would have failed to flash. | 16:44:42 |
| rosssmyth | I also just opened an issue because the armv6-m machinery is messed up and doesn't generate the correct gcc | 16:45:12 |
| rosssmyth | * I also just opened an issue because the armv6-m machinery is messed up and doesn't generate the correct gcc wrapper | 16:45:19 |
