ld: dangerous relocation: overflow after relaxation

[jcsbanks]

I want to place a std::map in flash which has almost 800 items like these:

Code: Select all

const std::map<const std::string, const std::string> dtc_lookup = {
	{"P0010","-A- Camshaft Pos. Actuator Circ. Bank 1 Malfunction"},
	
	...
	
	{"P1866","Data Bus Powertrain Missing messages"}
};

Problem is I get dangerous relocation errors on linking.

If I reduce the number of items to 600 it works. The size of the include file is about 43KB, so reducing it might coincide with about 32KB of data perhaps.

I've broken them up by the first digit after the P into two std::map, but would like to understand why the relocation fails and if there is a compiler option or parameter I can attach to the std::map that indicates to the compiler/linker how it can deal with it better.

[jcsbanks]

After breaking them up, even without actually using the std::map, it hangs on startup (and the interrupt watchdog timer resets even when extended to 3000ms) unless the length of the std::map is reduced. 100 items works, 300 doesn't. Accessing the std::map with 100 items is fast and works well.

Code: Select all

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x401bc426  PS      : 0x00060d34  A0      : 0x800d6249  A1      : 0x3ffbc210
0x401bc426: esp_pm_impl_waiti at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/pm_esp32.c:487

A2      : 0x00000000  A3      : 0x00000001  A4      : 0x00000000  A5      : 0x00000001
A6      : 0x00060020  A7      : 0x00000000  A8      : 0x800d50f2  A9      : 0x3ffbc1e0
A10     : 0x00000000  A11     : 0x40085da0  A12     : 0x00060020  A13     : 0x3ffbb690
0x40085da0: _free_r at C:/msys32/home/jcsba/esp/esp-idf/components/newlib/syscalls.c:41

A14     : 0x00000001  A15     : 0x3ffbbb88  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

ELF file SHA256: 2943cab0b68ec1b76584ac565c51e27d1f95cb1c3394f896f7ae5475045c9a28

Backtrace: 0x401bc426:0x3ffbc210 0x400d6246:0x3ffbc230 0x400935dd:0x3ffbc250 0x40094535:0x3ffbc270
0x401bc426: esp_pm_impl_waiti at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/pm_esp32.c:487

0x400d6246: esp_vApplicationIdleHook at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/freertos_hooks.c:86

0x400935dd: prvIdleTask at C:/msys32/home/jcsba/esp/esp-idf/components/freertos/tasks.c:4439

0x40094535: vPortTaskWrapper at C:/msys32/home/jcsba/esp/esp-idf/components/freertos/port.c:435


Core 1 register dump:
PC      : 0x401bc426  PS      : 0x00060f34  A0      : 0x800d6249  A1      : 0x3ffc3650
0x401bc426: esp_pm_impl_waiti at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/pm_esp32.c:487

A2      : 0x00000000  A3      : 0x80000001  A4      : 0x00000000  A5      : 0x00000001
A6      : 0x00060f20  A7      : 0x00000000  A8      : 0x800d50f2  A9      : 0x3ffc3620
A10     : 0x00000000  A11     : 0x00060f23  A12     : 0x00060f20  A13     : 0x3ffba598
A14     : 0x00000015  A15     : 0x3ffc4410  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

ELF file SHA256: 2943cab0b68ec1b76584ac565c51e27d1f95cb1c3394f896f7ae5475045c9a28

Backtrace: 0x401bc426:0x3ffc3650 0x400d6246:0x3ffc3670 0x400935dd:0x3ffc3690 0x40094535:0x3ffc36b0
0x401bc426: esp_pm_impl_waiti at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/pm_esp32.c:487

0x400d6246: esp_vApplicationIdleHook at C:/msys32/home/jcsba/esp/esp-idf/components/esp32/freertos_hooks.c:86

0x400935dd: prvIdleTask at C:/msys32/home/jcsba/esp/esp-idf/components/freertos/tasks.c:4439

0x40094535: vPortTaskWrapper at C:/msys32/home/jcsba/esp/esp-idf/components/freertos/port.c:435

[jcsbanks]

CXXFLAGS += -mtext-section-literals
CXXFLAGS += -ffunction-sections

or

CFLAGS += -mtext-section-literals
CFLAGS += -ffunction-sections

in component.mk didn't help the dangerous relocation with the 600+ length std::map. Removing const from the std::map or increasing the stack size for main or the task using the std::map didn't help.

[WiFive]

IDK about the linker error but won't a copy of that data end up in heap when the map is initialized?

[jcsbanks]

It prob would and that might be the problem at startup when large. I changed it to an array of struct with const uint16_t and const char* and a binary search in C99 and it works great. I like std::map but it is too abstracted and heavy for this I think.

[jcsbanks]

It scales well to a list of over 8000 uint16_t/string pairs using C99 binary search instead of std::map. Results appear instant to the user in the browser.

[WiFive]

Cool, you doing a VW/Audi scan tool?

[jcsbanks]

ECU flasher mainly, but added the fault code scan before the flash as a safety feature and a utility that can be used even when not flashing, along with datalogging and custom ECU features like flex fuel and calibrating whilst engine running. The ESP32 has made it all possible in a tiny device