Linker Failed to Assign Correct Address to Section End (IDFGH-7869)

[MarsTechHAN]

Environment

• Development Kit: Custom Design
• Module or chip used: ESP32-WROOM-32D (V3)
• IDF version: v4.4
• Build System: idf.py
• Compiler version: xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2021r1) 8.4.0
• Operating System: Windows PowerShell
• Using an IDE?: No
• Power Supply: External

Problem Description

// in lang.h
#define LITTER_LANG_EXPORT_CONSTANT(CONST_STR, CONST_NAME, CONST_VAL)  \
    static constant_ptr_t ptr_##CONST_NAME             \
    __attribute((used, section("LITTER_LANG_CONST_SECTION"))) = { \
        .value = CONST_VAL,                           \
        .name = CONST_STR                           \
    }

// in other.c
LITTER_LANG_EXPORT_CONSTANT("ABC", ABC, 3);
LITTER_LANG_EXPORT_CONSTANT("ABCD", ABCD, 4);

// in lang.c
#define get_section_elem_ptr(section_name, type_t) \
    ({ \
        extern type_t __start_##section_name; \
        &__start_##section_name; \
    })

#define get_section_elem_end_ptr(section_name, type_t) \
    ({ \
        extern type_t __stop_##section_name; \
        &__stop_##section_name; \
    })
 
constant_ptr_t *lang_const_list = get_section_elem_ptr(LITTER_LANG_CONST_SECTION, constant_ptr_t);
constant_ptr_t *lang_const_list_end = get_section_elem_end_ptr(LITTER_LANG_CONST_SECTION, constant_ptr_t);

ets_printf("start address: 0x%x, end address: 0x%x\n", lang_const_list, lang_const_list_end);
for(int i=0; i<2; i++){
        ets_printf("\t%s = %d\n", (lang_const_list + i)->name, (lang_const_list + i)->value);
}

Expected Behavior

lang_const_list_end - lang_const_list_start should result in the length of the section

Actual Behavior

start address: 0x3f404aec, end address: 0x3f404aec
        ABCD = 4
        ABC = 3

Other items if possible

elf file: lang_script.zip

[igrr]

@MarsTechHAN could you please attach the linker script or linker fragment file where you define this section?

[MarsTechHAN]

Hi. I do not use the linker fragment file with this code. I took a try, but it made no difference, so I just deleted it.

[igrr]

Somehow the values from the ELF file don't match the log in the issue description, and the behavior looks correct:

3f404aec A _rodata_end
3f404aec D __start_LITTER_LANG_CONST_SECTION
3f404aec d ptr_ABCD
3f404af4 d ptr_ABC
3f404afc D __stop_LITTER_LANG_CONST_SECTION

(from the output of xtensa-esp32-elf-nm lang_script.elf | sort)

Based on this, I can't explain why the value of __stop_LITTER_LANG_CONST_SECTION in your log is 0x3f404afc. I couldn't compile your code snippet to reproduce the issue, since some definitions are missing (like constant_ptr_t). Could you please either provide the complete sample to reproduce the issue, or do some further troubleshooting on your end to figure out why the wrong value is printed?

[MarsTechHAN]

Thanks for the reply. Yes, it was part of my issue. I check the elf, and everything looks correct, but the program printed the wrong address.
Here is what I got with the program below.

Here is the minimal reproducible program.

#include <stdio.h>
#include <math.h>

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/event_groups.h"

typedef struct __attribute__((packed, aligned(4))) constant_ptr_s {
   const char *name;
   const int value;
} constant_ptr_t;

#define LITTER_LANG_EXPORT_CONSTANT(CONST_STR, CONST_NAME, CONST_VAL)  \
    static constant_ptr_t ptr_##CONST_NAME             \
    __attribute((used, section("LITTER_LANG_CONST_SECTION"))) = { \
        .value = CONST_VAL,                           \
        .name = CONST_STR                           \
    }

#define get_section_elem_ptr(section_name, type_t) \
    ({ \
        extern type_t __start_##section_name; \
        &__start_##section_name; \
    })

#define get_section_elem_end_ptr(section_name, type_t) \
    ({ \
        extern type_t __stop_##section_name; \
        &__stop_##section_name; \
    })

LITTER_LANG_EXPORT_CONSTANT("ABC", ABC, 3);
LITTER_LANG_EXPORT_CONSTANT("ABCD", ABCD, 4);

void app_main() {
    constant_ptr_t *lang_const_list = get_section_elem_ptr(LITTER_LANG_CONST_SECTION, constant_ptr_t);
    constant_ptr_t *lang_const_list_end = get_section_elem_end_ptr(LITTER_LANG_CONST_SECTION, constant_ptr_t);

    ets_printf("start address: 0x%x, end address: 0x%x\n", lang_const_list, lang_const_list_end);
    
  while(1){
    vTaskDelay(1000 / portTICK_PERIOD_MS);
  }
}

[igrr]

Thank you for the reproducer! I do observe the issue as well now.

I have checked that the issue also happens with latest master branch of GNU binutils. On the other hand, the issue doesn't occur when building the same program for ESP32-C3 (RISC-V architecture). Looks like this might be an Xtensa specific issue in binutils.

We will look at this issue but it might take some time, since some of the team members are on leave now.

I can offer you a workaround for the time being. That is, to define the linker script fragment for the section you have added.

Some example pointers:

• linker.lf file handling the .plugins_desc section: https://github.com/espressif/esp-idf/blob/master/examples/build_system/cmake/plugins/components/plugins/linker.lf
• referencing it in CMake:

  esp-idf/examples/build_system/cmake/plugins/components/plugins/CMakeLists.txt

  Line 3 in 075e072

  LDFRAGMENTS linker.lf)

• section attribute in C code:

  esp-idf/examples/build_system/cmake/plugins/components/plugin_hello/plugin_hello.c

  Line 28 in 075e072

  static const example_plugin_desc_t __attribute__((section(".plugins_desc"),used)) PLUGIN = {

• iterating over the section:

  esp-idf/examples/build_system/cmake/plugins/components/plugins/plugins.c

  Lines 66 to 70 in 075e072

  	extern const example_plugin_desc_t _plugins_array_start;
  	extern const example_plugin_desc_t _plugins_array_end;
  	for (const example_plugin_desc_t* it = &_plugins_array_start; it != &_plugins_array_end; ++it) {
  	printf("- Plugin '%s', function greet=%p\n", it->name, it->greet);
  	}

Hope this helps you move forward with your project. We'll keep the issue open until the bug you have reported is addressed.

[MarsTechHAN]

Hi. Thanks for the help. My project now works perfectly, looking forward to seeing the issue get resolved.

[Alvin1Zhang]

Thanks for reporting, fix is available at 0007754, feel free to reopen.