info sections (like .defmt) are downloaded instead of discarded on the esp8266

[t-moe]

I'm using the esp8266 with defmt.
defmt uses a linker script defmt.x.in that adds a custom section:

SECTIONS
{

  .defmt 1 (INFO) :
  {
  /* ....*/
  }
}

As a result the elf file looks like this (xtensa-lx106-elf-readelf -S mytarget):

There are 18 section headers, starting at offset 0x8108:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .rtc.text         PROGBITS        60001000 004cad 000000 00   W  0   0  1
  [ 2] .rtc.data         PROGBITS        60001000 004cad 000000 00   W  0   0  1
  [ 3] .rtc.bss          PROGBITS        60001000 004cad 000000 00   W  0   0  1
  [ 4] .rtc.noinit       PROGBITS        60001000 004cad 000000 00   W  0   0  1
  [ 5] .vectors          PROGBITS        40100000 002000 000080 00  AX  0   0  4
  [ 6] .text             PROGBITS        40210000 003000 001cad 00  AX  0   0  4
  [ 7] .rodata           PROGBITS        3ffe8000 001000 0009f0 00   A  0   0 16
  [ 8] .data             PROGBITS        3ffe89f0 004cb0 000000 00  WA  0   0  4
  [ 9] .bss              NOBITS          3ffe89f0 0019f0 000009 00  WA  0   0  4
  [10] .noinit           PROGBITS        3ffe89fc 004cb0 000000 00   W  0   0  4
  [11] .rwtext           PROGBITS        40100100 002100 00062a 00  AX  0   0  4
  [12] .text_heap_start  PROGBITS        4010072c 004cb0 000000 00   W  0   0  4
  [13] .heap_start       PROGBITS        3ffe89fc 004cb0 000000 00   W  0   0  4
  [14] .defmt            PROGBITS        00000001 004cb0 000003 00      0   0  1
  [15] .symtab           SYMTAB          00000000 004cb4 000f00 10     16  73  4
  [16] .strtab           STRTAB          00000000 005bb4 0024d0 00      0   0  1
  [17] .shstrtab         STRTAB          00000000 008084 000081 00      0   0  1

(not sure why the info flag is not set on .defmt)

The current code of espflash, does not discard that .defmt section and instead downloads it.
As a result the chip won't boot up.

Hacky patch, to get it working:

diff --git a/espflash/src/elf.rs b/espflash/src/elf.rs
--- a/espflash/src/elf.rs	(revision 3c145c98f69168f54e888287cbea3bbfc40440e5)
+++ b/espflash/src/elf.rs	(date 1694683247711)
@@ -84,6 +84,7 @@
                         && header.get_type() == Ok(ShType::ProgBits)
                         && header.offset() > 0
                         && header.address() > 0
+                        && ! matches!(header.get_name(&self.elf), Ok(".defmt"))
                 })
                 .flat_map(move |header| {
                     let addr = header.address() as u32;

[MabezDev]

How did you add defmt support? The official template marks the defmt section as INFO and therefore shouldn't have the PROGBITS type.

https://github.com/knurling-rs/defmt/blob/82882c8b5ddfb58784e3275e70a6e3f270074885/defmt/defmt.x.in#L9-L31

[t-moe]

I also find it a bit strange.
I've added it as suggested by defmt:
here is me .cargo/config.toml:

[target.xtensa-esp8266-none-elf]
runner = "espflash --monitor"
rustflags = [
  "-C", "link-arg=-nostartfiles",
  "-C", "link-arg=-Wl,-Tlink.x",
  "-C", "link-arg=-Wl,-Tdefmt.x",
]

[build]
target = "xtensa-esp8266-none-elf"


[unstable]
build-std = ["core"]

Is this maybe a problem of the (gcc) linker used with the esp8266? (using xtensa-lx106-elf-gcc (GCC) 10.3.0 here)

[MabezDev]

Hmm actually it appears .defmt is marked as a PROGBITS section. The thing is, espflash should be discarding it because its not in a valid address space for the esp8266. Not sure why it isn't.

[t-moe]

Yes it is strange that even if I use the official template .defmt ends up being marked as PROGBITS section.

As for the discarding: I think for the esp8266 the address space is not checked?

[MabezDev]

At that would be it. Sorry its been a long long time since I looked at the esp8266 stuff. Would you mind sending a PR to check the address space when merging sections?

[t-moe]

Actually, also on the esp32c3 the .defmt section ends up with type progbits..

https://github.com/esp-rs/no_std-training/tree/main/intro/hello-world, but with defmt added

 readelf -S target/riscv32imc-unknown-none-elf/debug/hello_world
There are 36 section headers, starting at offset 0x589c88:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text.dummy       NOBITS          42000020 000234 000000 00   A  0   0  1
  [ 2] .text_init        PROGBITS        42000020 001020 0000f0 00  AX  0   0  4
  [ 3] .text             PROGBITS        42000110 001110 01fc30 00  AX  0   0  4
  [ 4] .text_dummy       NOBITS          3c000000 021000 020020 00  AX  0   0  1
  [ 5] .rodata           PROGBITS        3c020020 021020 005e44 00  AM  0   0 16
  [ 6] .rodata.wifi      PROGBITS        3c025e64 026e64 000000 00   A  0   0  4
  [ 7] .trap             PROGBITS        40380000 027000 0007a8 00  AX  0   0 256
  [ 8] .rwtext           PROGBITS        403807a8 0277a8 0007f8 00  AX  0   0  4
  [ 9] .rwtext.wifi      PROGBITS        40380fa0 027fa0 000000 00  AX  0   0  1
  [10] .rwdata_dummy     NOBITS          3fc80000 028000 000fa0 00  AX  0   0  1
  [11] .data             PROGBITS        3fc80fa0 028000 000000 00  AX  0   0  4
  [12] .bss              NOBITS          3fc80fa0 028fa0 000010 00  WA  0   0  4
  [13] .noinit           NOBITS          3fc80fb0 028fa0 000000 00  WA  0   0  4
  [14] .data.wifi        PROGBITS        3fc80fb0 028fa0 000000 00  WA  0   0  1
  [15] .stack_end        NOBITS          3fc80fb0 028fa0 000000 00  WA  0   0  4
  [16] .rtc_fast.text    PROGBITS        50000000 028fa0 000000 00  WA  0   0  1
  [17] .rtc_fast.data    PROGBITS        50000000 028fa0 000000 00  WA  0   0  1
  [18] .rtc_fast.bss     NOBITS          50000000 028fa0 000000 00  WA  0   0  1
  [19] .rtc_fast.noinit  NOBITS          50000000 028fa0 000000 00  WA  0   0  1
  [20] .defmt            PROGBITS        00000000 028fa0 000003 00      0   0  1
  [21] .debug_abbrev     PROGBITS        00000000 028fa3 006a7d 00      0   0  1
  [22] .debug_info       PROGBITS        00000000 02fa20 11bb2e 00      0   0  1
  [23] .debug_aranges    PROGBITS        00000000 14b54e 00bc20 00      0   0  1
  [24] .debug_ranges     PROGBITS        00000000 15716e 01c8b8 00      0   0  1
  [25] .debug_str        PROGBITS        00000000 173a26 13d528 01  MS  0   0  1
  [26] .debug_pubnames   PROGBITS        00000000 2b0f4e 06320e 00      0   0  1
  [27] .debug_pubtypes   PROGBITS        00000000 31415c 0a1b89 00      0   0  1
  [28] .riscv.attributes RISCV_ATTRIBUTE 00000000 3b5ce5 00002b 00      0   0  1
  [29] .debug_frame      PROGBITS        00000000 3b5d10 02612c 00      0   0  4
  [30] .debug_line       PROGBITS        00000000 3dbe3c 0937c8 00      0   0  1
  [31] .debug_loc        PROGBITS        00000000 46f604 002714 00      0   0  1
  [32] .comment          PROGBITS        00000000 471d18 000013 01  MS  0   0  1
  [33] .symtab           SYMTAB          00000000 471d2c 101520 10     35 65131  4
  [34] .shstrtab         STRTAB          00000000 57324c 000190 00      0   0  1
  [35] .strtab           STRTAB          00000000 5733dc 0168aa 00      0   0  1

The only difference is, that addr=0 and on the esp8266 addr=1. An addr=0 will cause the segment to be discarded (elf.rs)

Regarding the implementation:
for the esp8266 the addr_is_flash check is already added. but if addr_is_flash returns false the segment will simply end up in ram....

How do we fix this?

[MabezDev]

Hmm, I guess understanding why it's assigned an address of 1, when on every other chip the defmt section has an address of 0, is how we solve this. Of the top of my head though, I don't have any idea why this would be the case :(

[jessebraham]

We've decided to drop support for the ESP8266 (see #576), so closing this issue.