Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor xtask to bind and compile for every target. #15

Merged
merged 5 commits into from
Oct 5, 2023

Conversation

AnthonyGrondin
Copy link
Contributor

@AnthonyGrondin AnthonyGrondin commented Sep 6, 2023

I've refactored the xtask process to be able to compile mbedtls without needing a bash script, to try and improve user experience and compatibility. Defining a config per chip also allows a finer grain control over which peripherals we provide an alternative for.

⚠️ NOTE ⚠️
Using different configs will generate different bindings, which might be an issue.

What's left to be done:
- binding fails when the config file is named mbedtls_config.h saying it cannot find time.h.
- Adding binding and compilation target for Xtensa chips.

Usage

.cargo/config.toml

[alias]
xtask = "run --manifest-path ./xtask/Cargo.toml --"

To generate bindings:

cargo +stable xtask bindings

To compile libs:

cargo +stable xtask compile

@AnthonyGrondin AnthonyGrondin marked this pull request as ready for review September 7, 2023 08:47
@AnthonyGrondin
Copy link
Contributor Author

I think this should be ready for a review.

I still don't know how to manage the different bindings per chip, if we use different headers.
Either we generate into a unique file per chip, and then we use features / cfg to export the right one.

Or we generate everything in the same bindgen file, and we use cfg / features to specify which signature per chip of they differ.

@bjoernQ
Copy link
Collaborator

bjoernQ commented Sep 12, 2023

In esp-wifi we have bindings per chip and use a feature + cfg to select the right binding. Probably we can do the same here

- Add support for esp32s2
- Move headers file back to esp-mbedtls-sys
- Update bindgen
- Update esp-hal, esp-wifi
@AnthonyGrondin
Copy link
Contributor Author

AnthonyGrondin commented Sep 14, 2023

Sorry, this PR got quite lengthy.

  • I've refactored the bindings to do like esp-wifi.
  • I've updated esp-hal and esp-wifi.
  • I've also update the bindgen. I can't seem to figure out why the newlines are broken now. It generate the docs into a single line.
  • I've added support for esp32s2.

TODO

  • Testing every example of every chip
  • Fix compilation error

Every library compiles successfully, but on Xtensa targets, I'm getting errors when trying to run an example.

ssl_msg.c:(.text.mbedtls_ssl_write_handshake_msg_ext+0x1a2): dangerous relocation: call8: call target out of range: calloc
ssl_msg.c:(.text.mbedtls_ssl_write_handshake_msg_ext+0x1b7): dangerous relocation: call8: call target out of range: calloc
ssl_msg.c:(.text.mbedtls_ssl_write_handshake_msg_ext+0x1c1): dangerous relocation: call8: call target out of range: free

@bjoernQ
Copy link
Collaborator

bjoernQ commented Sep 14, 2023

Maybe we need to pass https://gcc.gnu.org/onlinedocs/gcc/Xtensa-Options.html#index-mlongcalls to the compiler on Xtensa

@AnthonyGrondin
Copy link
Contributor Author

AnthonyGrondin commented Sep 15, 2023

I've done a minimal testing on esp32-s3 and esp32-c3.

I don't know how rigorous we want to be on testing.

Edit: I just realized how large the binaries generated are, compared to origin, I think this should be looked at. It's over twice the size.

@AnthonyGrondin
Copy link
Contributor Author

AnthonyGrondin commented Sep 15, 2023

Using clang, I was able to reduce binary sizes a bit, but not to the same level as upstream:

This PR @90568c3:

[4.0K]  libs/
├── [4.0K]  riscv32imc-unknown-none-elf
│   ├── [1.2M]  libmbedcrypto.a
│   ├── [745K]  libmbedtls.a
│   └── [131K]  libmbedx509.a
├── [4.0K]  xtensa-esp32-none-elf
│   ├── [1.5M]  libmbedcrypto.a
│   ├── [447K]  libmbedtls.a
│   └── [166K]  libmbedx509.a
├── [4.0K]  xtensa-esp32s2-none-elf
│   ├── [1.5M]  libmbedcrypto.a
│   ├── [447K]  libmbedtls.a
│   └── [166K]  libmbedx509.a
└── [4.0K]  xtensa-esp32s3-none-elf
    ├── [1.5M]  libmbedcrypto.a
    ├── [447K]  libmbedtls.a
    └── [166K]  libmbedx509.a

5 directories, 12 files

With CLANG:

[4.0K]  libs/
├── [4.0K]  riscv32imc-unknown-none-elf
│   ├── [1.2M]  libmbedcrypto.a
│   ├── [745K]  libmbedtls.a
│   └── [131K]  libmbedx509.a
├── [4.0K]  xtensa-esp32-none-elf
│   ├── [1.2M]  libmbedcrypto.a
│   ├── [300K]  libmbedtls.a
│   └── [113K]  libmbedx509.a
├── [4.0K]  xtensa-esp32s2-none-elf
│   ├── [1.2M]  libmbedcrypto.a
│   ├── [300K]  libmbedtls.a
│   └── [113K]  libmbedx509.a
└── [4.0K]  xtensa-esp32s3-none-elf
    ├── [1.2M]  libmbedcrypto.a
    ├── [300K]  libmbedtls.a
    └── [113K]  libmbedx509.a

5 directories, 12 files

Origin:

[4.0K]  libs/
├── [4.0K]  riscv32imc-unknown-none-elf
│   ├── [939K]  libmbedcrypto.a
│   ├── [587K]  libmbedtls.a
│   └── [111K]  libmbedx509.a
├── [4.0K]  xtensa-esp32-none-elf
│   ├── [683K]  libmbedcrypto.a
│   ├── [196K]  libmbedtls.a
│   └── [ 68K]  libmbedx509.a
├── [4.0K]  xtensa-esp32s2-none-elf
│   ├── [683K]  libmbedcrypto.a
│   ├── [196K]  libmbedtls.a
│   └── [ 68K]  libmbedx509.a
└── [4.0K]  xtensa-esp32s3-none-elf
    ├── [683K]  libmbedcrypto.a
    ├── [196K]  libmbedtls.a
    └── [ 68K]  libmbedx509.a

5 directories, 12 files

I can't seem to figure out what else to do to reduce the binary size. I think they should still be optimized and reduced.

@bjoernQ
Copy link
Collaborator

bjoernQ commented Sep 18, 2023

Besides the lib size looks quite good to me.
Maybe we should remove build-std from .cargo/config.toml since it makes running the xtask inconvenient. We can just add it to the instructions for running the example since we already need to specify the target there.

There is a warning about Manually-specified variables were not used by the project: CMAKE_ASM_FLAGS but seems the CMake crate does that and there is nothing to do about it.

.host("riscv32") looks suspicious - I think it's best to just not specify host at all or was there a specific reason to set it manually to this?

I have no idea what causes the increased size. I thought it's just he .a files and the actual code isn't that different (checked with size bin-util). Seems some functions are larger (makes sense on Xtensa because of the longcalls) and some are even smaller.

The final binaries are smaller now but that might be mainly because of optimizations in esp-wifi itself.

There is not much differences in how Clang is called (comparing the previous shell file and the output of the CMake crate). (But there are some differences - maybe that is the clue)

@AnthonyGrondin
Copy link
Contributor Author

.host("riscv32") looks suspicious - I think it's best to just not specify host at all or was there a specific reason to set it manually to this?

On my side, I would get a $HOST not defined error if I didn't specify the host. Maybe there are better ways to handle this. I don't really know how the host affects the code generation.

The final binaries are smaller now but that might be mainly because of optimizations in esp-wifi itself.

I do think it's mainly because of the improvements in esp-wifi and a bumped MSRV. I believe that .a libs are directly included whole in the binary (I don't actually know). I don't think with the current config, that the unused symbols get removed at compile time.

Since mbedtls SHA doesn't change, the generated libraries shouldn't be twice the size.

I've looked a bit at the binaries, I hope this gives us some clue:

  • ar -t gives the same obj list
  • ar -x gives obj files with different sha1sum
  • nm gives a different symbol table.
  • objdump gives different symbols

nm

Origin:
nm riscv_obj/version.c.obj

00000000 r .LC0
00000008 r .LC1
00000000 T mbedtls_version_get_number
00000006 T mbedtls_version_get_string
00000040 T mbedtls_version_get_string_full
         U memcpy

This PR:
nm riscv_obj/version.c.obj

00000000 t .L0
00000002 t .L0
00000000 r .LC0
00000000 r .LC1
00000000 T mbedtls_version_get_number
00000000 T mbedtls_version_get_string
00000000 T mbedtls_version_get_string_full
         U memcpy

objdump

Origin:
riscv32-esp-elf-objdump libs_old_objects/version.c.obj

libs_old_objects/version.c.obj:     file format elf32-littleriscv


Disassembly of section .text:

00000000 <mbedtls_version_get_number>:
   0:   03040537                lui     a0,0x3040
   4:   8082                    ret

00000006 <mbedtls_version_get_string>:
   6:   000007b7                lui     a5,0x0
   a:   00078793                mv      a5,a5
   e:   0007c803                lbu     a6,0(a5) # 0 <mbedtls_version_get_number>
  12:   0017c583                lbu     a1,1(a5)
  16:   0027c603                lbu     a2,2(a5)
  1a:   0037c683                lbu     a3,3(a5)
  1e:   0047c703                lbu     a4,4(a5)
  22:   0057c783                lbu     a5,5(a5)
  26:   01050023                sb      a6,0(a0) # 3040000 <mbedtls_version_get_string_full+0x303ffc0>
  2a:   00b500a3                sb      a1,1(a0)
  2e:   00c50123                sb      a2,2(a0)
  32:   00d501a3                sb      a3,3(a0)
  36:   00e50223                sb      a4,4(a0)
  3a:   00f502a3                sb      a5,5(a0)
  3e:   8082                    ret

00000040 <mbedtls_version_get_string_full>:
  40:   000005b7                lui     a1,0x0
  44:   463d                    li      a2,15
  46:   00058593                mv      a1,a1
  4a:   00000317                auipc   t1,0x0
  4e:   00030067                jr      t1 # 4a <mbedtls_version_get_string_full+0xa>

This PR:
riscv32-esp-elf-objdump -d libs_objects/version.c.obj

libs_objects/version.c.obj:     file format elf32-littleriscv


Disassembly of section .text.mbedtls_version_get_number:

00000000 <mbedtls_version_get_number>:
   0:   03040537                lui     a0,0x3040
   4:   8082                    ret

Disassembly of section .text.mbedtls_version_get_string:

00000000 <mbedtls_version_get_string>:
   0:   00000797                auipc   a5,0x0
   4:   00078793                mv      a5,a5
   8:   0007c803                lbu     a6,0(a5) # 0 <mbedtls_version_get_string>
   c:   0017c583                lbu     a1,1(a5)
  10:   0027c603                lbu     a2,2(a5)
  14:   0037c683                lbu     a3,3(a5)
  18:   0047c703                lbu     a4,4(a5)
  1c:   0057c783                lbu     a5,5(a5)
  20:   01050023                sb      a6,0(a0) # 3040000 <mbedtls_version_get_string+0x3040000>
  24:   00b500a3                sb      a1,1(a0)
  28:   00c50123                sb      a2,2(a0)
  2c:   00d501a3                sb      a3,3(a0)
  30:   00e50223                sb      a4,4(a0)
  34:   00f502a3                sb      a5,5(a0)
  38:   8082                    ret

Disassembly of section .text.mbedtls_version_get_string_full:

00000000 <mbedtls_version_get_string_full>:
   0:   463d                    li      a2,15
   2:   00000597                auipc   a1,0x0
   6:   00058593                mv      a1,a1
   a:   00000317                auipc   t1,0x0
   e:   00030067                jr      t1 # a <mbedtls_version_get_string_full+0xa>

@bjoernQ
Copy link
Collaborator

bjoernQ commented Sep 19, 2023

On my side, I would get a $HOST not defined error if I didn't specify the host. Maybe there are better ways to handle this. I don't really know how the host affects the code generation.

I guess the host should ideally not change the cross-compiled code at all - so it's probably fine it just looked a bit strange.

Maybe it's worth to try changing the original compile script to pass the exact same arguments to CMake and see if it produces the same libraries. I guess it will.

@AnthonyGrondin
Copy link
Contributor Author

Using the original Bash build script (build_all.sh), for esp32c3 I get a 1.7MB folder like it should be.
Using the Xtask, which uses the same toolchain cmake file, produces a 2.2MB folder for riscv32imc-unknown-none-elf.

I really feel it's something in the configuration and now cmake is called, but I don't know what. I've tried changing the host() for fun and it doesn't change anything. It's like finding a needle in a haystack.

@bugadani Maybe you can help with this.

@bugadani
Copy link
Contributor

Maybe you can help with this.

I can throw in random ideas but I'm very unlikely to be much help here. I can see that the latest rev uses gcc and its toolchain files, while the main branch uses clang's toolchain file so I assume it also uses clang, but that's about all the difference I see.

Are the archives actually meaningfully different or does one compiler just throw in a bunch of random zero-sized stuff and different metadata? What you pasted here is essentially identical

@AnthonyGrondin
Copy link
Contributor Author

I've dumped the bytes of the generated version.c.obj (randomly chosen, figured I'd use a small one for simplicity), and it looks like there are extra symbols. I don't know enough about this toolchain to know from where they could come from.

Using the same cmake toolchain file toolchain-esp32c3.cmake origin being generated with build_all.sh and this PR being generated with the xtask.

origin:
xxd version.c.obj

00000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00000010: 0100 f300 0100 0000 0000 0000 0000 0000  ................
00000020: 3403 0000 0100 0000 3400 0000 0000 2800  4.......4.....(.
00000030: 0b00 0a00 3705 0403 8280 b707 0000 9387  ....7...........
00000040: 0700 03c8 0700 83c5 1700 03c6 2700 83c6  ............'...
00000050: 3700 03c7 4700 83c7 5700 2300 0501 a300  7...G...W.#.....
00000060: b500 2301 c500 a301 d500 2302 e500 a302  ..#.......#.....
00000070: f500 8280 b705 0000 3d46 9385 0500 1703  ........=F......
00000080: 0000 6700 0300 0000 332e 342e 3000 0000  ..g.....3.4.0...
00000090: 6d62 6564 2054 4c53 2033 2e34 2e30 0000  mbed TLS 3.4.0..
000000a0: 4743 433a 2028 6372 6f73 7374 6f6f 6c2d  GCC: (crosstool-
000000b0: 4e47 2065 7370 2d31 322e 322e 305f 3230  NG esp-12.2.0_20
000000c0: 3233 3032 3038 2920 3132 2e32 2e30 0041  230208) 12.2.0.A
000000d0: 2500 0000 7269 7363 7600 011b 0000 0004  %...riscv.......
000000e0: 1005 7276 3332 6932 7031 5f6d 3270 305f  ..rv32i2p1_m2p0_
000000f0: 6332 7030 0000 0000 0000 0000 0000 0000  c2p0............
00000100: 0000 0000 0000 0000 0100 0000 0000 0000  ................
00000110: 0000 0000 0400 f1ff 0000 0000 0000 0000  ................
00000120: 0000 0000 0300 0100 0000 0000 0000 0000  ................
00000130: 0000 0000 0300 0300 0000 0000 0000 0000  ................
00000140: 0000 0000 0300 0400 0b00 0000 0000 0000  ................
00000150: 0000 0000 0000 0100 0000 0000 0000 0000  ................
00000160: 0000 0000 0300 0500 0e00 0000 0000 0000  ................
00000170: 0000 0000 0000 0500 1300 0000 0800 0000  ................
00000180: 0000 0000 0000 0500 0000 0000 0000 0000  ................
00000190: 0000 0000 0300 0600 0000 0000 0000 0000  ................
000001a0: 0000 0000 0300 0700 1800 0000 0000 0000  ................
000001b0: 0600 0000 1200 0100 3300 0000 0600 0000  ........3.......
000001c0: 3a00 0000 1200 0100 4e00 0000 4000 0000  :.......N...@...
000001d0: 1200 0000 1200 0100 6e00 0000 0000 0000  ........n.......
000001e0: 0000 0000 1000 0000 0076 6572 7369 6f6e  .........version
000001f0: 2e63 0024 7800 2e4c 4330 002e 4c43 3100  .c.$x..LC0..LC1.
00000200: 6d62 6564 746c 735f 7665 7273 696f 6e5f  mbedtls_version_
00000210: 6765 745f 6e75 6d62 6572 006d 6265 6474  get_number.mbedt
00000220: 6c73 5f76 6572 7369 6f6e 5f67 6574 5f73  ls_version_get_s
00000230: 7472 696e 6700 6d62 6564 746c 735f 7665  tring.mbedtls_ve
00000240: 7273 696f 6e5f 6765 745f 7374 7269 6e67  rsion_get_string
00000250: 5f66 756c 6c00 6d65 6d63 7079 0000 0000  _full.memcpy....
00000260: 0600 0000 1a07 0000 0000 0000 0600 0000  ................
00000270: 3300 0000 0000 0000 0a00 0000 1b07 0000  3...............
00000280: 0000 0000 0a00 0000 3300 0000 0000 0000  ........3.......
00000290: 4000 0000 1a08 0000 0000 0000 4000 0000  @...........@...
000002a0: 3300 0000 0000 0000 4600 0000 1b08 0000  3.......F.......
000002b0: 0000 0000 4600 0000 3300 0000 0000 0000  ....F...3.......
000002c0: 4a00 0000 120e 0000 0000 0000 4a00 0000  J...........J...
000002d0: 3300 0000 0000 0000 002e 7379 6d74 6162  3.........symtab
000002e0: 002e 7374 7274 6162 002e 7368 7374 7274  ..strtab..shstrt
000002f0: 6162 002e 7265 6c61 2e74 6578 7400 2e64  ab..rela.text..d
00000300: 6174 6100 2e62 7373 002e 726f 6461 7461  ata..bss..rodata
00000310: 2e73 7472 312e 3400 2e63 6f6d 6d65 6e74  .str1.4..comment
00000320: 002e 7269 7363 762e 6174 7472 6962 7574  ..riscv.attribut
00000330: 6573 0000 0000 0000 0000 0000 0000 0000  es..............
00000340: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000350: 0000 0000 0000 0000 0000 0000 2000 0000  ............ ...
00000360: 0100 0000 0600 0000 0000 0000 3400 0000  ............4...
00000370: 5200 0000 0000 0000 0000 0000 0200 0000  R...............
00000380: 0000 0000 1b00 0000 0400 0000 4000 0000  ............@...
00000390: 0000 0000 6002 0000 7800 0000 0800 0000  ....`...x.......
000003a0: 0100 0000 0400 0000 0c00 0000 2600 0000  ............&...
000003b0: 0100 0000 0300 0000 0000 0000 8600 0000  ................
000003c0: 0000 0000 0000 0000 0000 0000 0100 0000  ................
000003d0: 0000 0000 2c00 0000 0800 0000 0300 0000  ....,...........
000003e0: 0000 0000 8600 0000 0000 0000 0000 0000  ................
000003f0: 0000 0000 0100 0000 0000 0000 3100 0000  ............1...
00000400: 0100 0000 3200 0000 0000 0000 8800 0000  ....2...........
00000410: 1700 0000 0000 0000 0000 0000 0400 0000  ................
00000420: 0100 0000 4000 0000 0100 0000 3000 0000  ....@.......0...
00000430: 0000 0000 9f00 0000 3000 0000 0000 0000  ........0.......
00000440: 0000 0000 0100 0000 0100 0000 4900 0000  ............I...
00000450: 0300 0070 0000 0000 0000 0000 cf00 0000  ...p............
00000460: 2600 0000 0000 0000 0000 0000 0100 0000  &...............
00000470: 0000 0000 0100 0000 0200 0000 0000 0000  ................
00000480: 0000 0000 f800 0000 f000 0000 0900 0000  ................
00000490: 0b00 0000 0400 0000 1000 0000 0900 0000  ................
000004a0: 0300 0000 0000 0000 0000 0000 e801 0000  ................
000004b0: 7500 0000 0000 0000 0000 0000 0100 0000  u...............
000004c0: 0000 0000 1100 0000 0300 0000 0000 0000  ................
000004d0: 0000 0000 d802 0000 5b00 0000 0000 0000  ........[.......
000004e0: 0000 0000 0100 0000 0000 0000            ............

this PR:
xxd version.c.obj

00000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00000010: 0100 f300 0100 0000 0000 0000 0000 0000  ................
00000020: 6c04 0000 0100 0000 3400 0000 0000 2800  l.......4.....(.
00000030: 1000 0f00 3705 0403 8280 0000 332e 342e  ....7.......3.4.
00000040: 3000 9707 0000 9387 0700 03c8 0700 83c5  0...............
00000050: 1700 03c6 2700 83c6 3700 03c7 4700 83c7  ....'...7...G...
00000060: 5700 2300 0501 a300 b500 2301 c500 a301  W.#.......#.....
00000070: d500 2302 e500 a302 f500 8280 6d62 6564  ..#.........mbed
00000080: 2054 4c53 2033 2e34 2e30 0000 3d46 9705   TLS 3.4.0..=F..
00000090: 0000 9385 0500 1703 0000 6700 0300 0047  ..........g....G
000000a0: 4343 3a20 2863 726f 7373 746f 6f6c 2d4e  CC: (crosstool-N
000000b0: 4720 6573 702d 3132 2e32 2e30 5f32 3032  G esp-12.2.0_202
000000c0: 3330 3230 3829 2031 322e 322e 3000 4125  30208) 12.2.0.A%
000000d0: 0000 0072 6973 6376 0001 1b00 0000 0410  ...riscv........
000000e0: 0572 7633 3269 3270 315f 6d32 7030 5f63  .rv32i2p1_m2p0_c
000000f0: 3270 3000 0000 0000 0000 0000 0000 0000  2p0.............
00000100: 0000 0000 0100 0000 0000 0000 0000 0000  ................
00000110: 0400 f1ff 0000 0000 0000 0000 0000 0000  ................
00000120: 0300 0100 0000 0000 0000 0000 0000 0000  ................
00000130: 0300 0200 0000 0000 0000 0000 0000 0000  ................
00000140: 0300 0300 0000 0000 0000 0000 0000 0000  ................
00000150: 0300 0400 0b00 0000 0000 0000 0000 0000  ................
00000160: 0000 0400 0000 0000 0000 0000 0000 0000  ................
00000170: 0300 0500 0000 0000 0000 0000 0000 0000  ................
00000180: 0300 0600 0b00 0000 0000 0000 0000 0000  ................
00000190: 0000 0600 0000 0000 0000 0000 0000 0000  ................
000001a0: 0300 0800 0000 0000 0000 0000 0000 0000  ................
000001b0: 0300 0900 0b00 0000 0000 0000 0000 0000  ................
000001c0: 0000 0900 0e00 0000 0000 0000 0000 0000  ................
000001d0: 0000 0500 1300 0000 0000 0000 0000 0000  ................
000001e0: 0000 0600 1800 0000 0000 0000 0000 0000  ................
000001f0: 0000 0800 1300 0000 0200 0000 0000 0000  ................
00000200: 0000 0900 0000 0000 0000 0000 0000 0000  ................
00000210: 0300 0b00 0000 0000 0000 0000 0000 0000  ................
00000220: 0300 0c00 1d00 0000 0000 0000 0600 0000  ................
00000230: 1200 0400 3800 0000 0000 0000 3a00 0000  ....8.......:...
00000240: 1200 0600 5300 0000 0000 0000 1200 0000  ....S...........
00000250: 1200 0900 7300 0000 0000 0000 0000 0000  ....s...........
00000260: 1000 0000 0076 6572 7369 6f6e 2e63 0024  .....version.c.$
00000270: 7800 2e4c 4330 002e 4c30 2000 2e4c 4331  x..LC0..L0 ..LC1
00000280: 006d 6265 6474 6c73 5f76 6572 7369 6f6e  .mbedtls_version
00000290: 5f67 6574 5f6e 756d 6265 7200 6d62 6564  _get_number.mbed
000002a0: 746c 735f 7665 7273 696f 6e5f 6765 745f  tls_version_get_
000002b0: 7374 7269 6e67 006d 6265 6474 6c73 5f76  string.mbedtls_v
000002c0: 6572 7369 6f6e 5f67 6574 5f73 7472 696e  ersion_get_strin
000002d0: 675f 6675 6c6c 006d 656d 6370 7900 0000  g_full.memcpy...
000002e0: 0000 0000 170d 0000 0000 0000 0000 0000  ................
000002f0: 3300 0000 0000 0000 0400 0000 180e 0000  3...............
00000300: 0000 0000 0400 0000 3300 0000 0000 0000  ........3.......
00000310: 0200 0000 170f 0000 0000 0000 0200 0000  ................
00000320: 3300 0000 0000 0000 0600 0000 1810 0000  3...............
00000330: 0000 0000 0600 0000 3300 0000 0000 0000  ........3.......
00000340: 0a00 0000 1216 0000 0000 0000 0a00 0000  ................
00000350: 3300 0000 0000 0000 002e 7379 6d74 6162  3.........symtab
00000360: 002e 7374 7274 6162 002e 7368 7374 7274  ..strtab..shstrt
00000370: 6162 002e 7465 7874 002e 6461 7461 002e  ab..text..data..
00000380: 6273 7300 2e74 6578 742e 6d62 6564 746c  bss..text.mbedtl
00000390: 735f 7665 7273 696f 6e5f 6765 745f 6e75  s_version_get_nu
000003a0: 6d62 6572 002e 726f 6461 7461 2e6d 6265  mber..rodata.mbe
000003b0: 6474 6c73 5f76 6572 7369 6f6e 5f67 6574  dtls_version_get
000003c0: 5f73 7472 696e 672e 7374 7231 2e34 002e  _string.str1.4..
000003d0: 7265 6c61 2e74 6578 742e 6d62 6564 746c  rela.text.mbedtl
000003e0: 735f 7665 7273 696f 6e5f 6765 745f 7374  s_version_get_st
000003f0: 7269 6e67 002e 726f 6461 7461 2e6d 6265  ring..rodata.mbe
00000400: 6474 6c73 5f76 6572 7369 6f6e 5f67 6574  dtls_version_get
00000410: 5f73 7472 696e 675f 6675 6c6c 2e73 7472  _string_full.str
00000420: 312e 3400 2e72 656c 612e 7465 7874 2e6d  1.4..rela.text.m
00000430: 6265 6474 6c73 5f76 6572 7369 6f6e 5f67  bedtls_version_g
00000440: 6574 5f73 7472 696e 675f 6675 6c6c 002e  et_string_full..
00000450: 636f 6d6d 656e 7400 2e72 6973 6376 2e61  comment..riscv.a
00000460: 7474 7269 6275 7465 7300 0000 0000 0000  ttributes.......
00000470: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000480: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000490: 0000 0000 1b00 0000 0100 0000 0600 0000  ................
000004a0: 0000 0000 3400 0000 0000 0000 0000 0000  ....4...........
000004b0: 0000 0000 0200 0000 0000 0000 2100 0000  ............!...
000004c0: 0100 0000 0300 0000 0000 0000 3400 0000  ............4...
000004d0: 0000 0000 0000 0000 0000 0000 0100 0000  ................
000004e0: 0000 0000 2700 0000 0800 0000 0300 0000  ....'...........
000004f0: 0000 0000 3400 0000 0000 0000 0000 0000  ....4...........
00000500: 0000 0000 0100 0000 0000 0000 2c00 0000  ............,...
00000510: 0100 0000 0600 0000 0000 0000 3400 0000  ............4...
00000520: 0600 0000 0000 0000 0000 0000 0200 0000  ................
00000530: 0000 0000 4d00 0000 0100 0000 3200 0000  ....M.......2...
00000540: 0000 0000 3c00 0000 0600 0000 0000 0000  ....<...........
00000550: 0000 0000 0400 0000 0100 0000 7c00 0000  ............|...
00000560: 0100 0000 0600 0000 0000 0000 4200 0000  ............B...
00000570: 3a00 0000 0000 0000 0000 0000 0200 0000  :...............
00000580: 0000 0000 7700 0000 0400 0000 4000 0000  ....w.......@...
00000590: 0000 0000 e002 0000 3000 0000 0d00 0000  ........0.......
000005a0: 0600 0000 0400 0000 0c00 0000 9d00 0000  ................
000005b0: 0100 0000 3200 0000 0000 0000 7c00 0000  ....2.......|...
000005c0: 0f00 0000 0000 0000 0000 0000 0400 0000  ................
000005d0: 0100 0000 d100 0000 0100 0000 0600 0000  ................
000005e0: 0000 0000 8c00 0000 1200 0000 0000 0000  ................
000005f0: 0000 0000 0200 0000 0000 0000 cc00 0000  ................
00000600: 0400 0000 4000 0000 0000 0000 1003 0000  ....@...........
00000610: 4800 0000 0d00 0000 0900 0000 0400 0000  H...............
00000620: 0c00 0000 f700 0000 0100 0000 3000 0000  ............0...
00000630: 0000 0000 9e00 0000 3000 0000 0000 0000  ........0.......
00000640: 0000 0000 0100 0000 0100 0000 0001 0000  ................
00000650: 0300 0070 0000 0000 0000 0000 ce00 0000  ...p............
00000660: 2600 0000 0000 0000 0000 0000 0100 0000  &...............
00000670: 0000 0000 0100 0000 0200 0000 0000 0000  ................
00000680: 0000 0000 f400 0000 7001 0000 0e00 0000  ........p.......
00000690: 1300 0000 0400 0000 1000 0000 0900 0000  ................
000006a0: 0300 0000 0000 0000 0000 0000 6402 0000  ............d...
000006b0: 7a00 0000 0000 0000 0000 0000 0100 0000  z...............
000006c0: 0000 0000 1100 0000 0300 0000 0000 0000  ................
000006d0: 0000 0000 5803 0000 1201 0000 0000 0000  ....X...........
000006e0: 0000 0000 0100 0000 0000 0000            ............

@bugadani
Copy link
Contributor

It feels like you're not passing some flags esp-idf passes, e.g. -fdata-sections -ffunction-sections. I wonder, can you print the actual commands used to build (by the original script & cmake files), and use that as your source truth?

- Fixes an issue caused by `cmake-rs` auto-generating C flags which caused a larger binary size than expected.
- Remove ESP32-S2 from justfile since it won't compile for async
@AnthonyGrondin AnthonyGrondin force-pushed the feat/improve-building-process branch from 76d7219 to e9cec52 Compare September 22, 2023 07:04
@AnthonyGrondin
Copy link
Contributor Author

The issue ended up being caused by cmake-rs automatically generating C flags from the toolchain file.

I haven't successfully got clang working to xtensa targets, hence whey they are still so large, but the last commit is still a considerable improvement.

This fixes an issue where docs would be generated on a single line instead of being properly normalized and formatted
@AnthonyGrondin
Copy link
Contributor Author

Sorry, this is a kind of a big PR.

I'm not sure what's left to be done. I was hoping to get the compilation with clang to produce the same binaries as origin, which are the smallest, too, but I don't think it really affects that much the total binary size. Especially with rustc and esp-wifi improvements, we should see smaller binary sizes.

I think eventually the compilation could be done in CI, when it detects a changes in the header files, so that users don't have to push their own compiled libs, to mitigate Supply chain attacks.

@@ -1,5 +1,5 @@
[target.xtensa-esp32-none-elf]
runner = "espflash flash --monitor"
runner = "espflash flash --monitor --baud 921600"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to not have a hardcoded baud-rate here (and in the other places)

Copy link
Collaborator

@bjoernQ bjoernQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good to me - Thanks for all the effort!

Maybe it would be worth to mention how to generate the bindings / compile the code in the README.md

Especially using +stable to make it not complain about the missing --target might not be obvious

@bjoernQ bjoernQ merged commit ea41ee7 into esp-rs:main Oct 5, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants