Missing linker warning for redeclaration of symbol?

[Sola85]

Board

ESP32 Dev Module

Device Description

plain module, no external hardware

Hardware Configuration

Version

v2.0.2

IDE Name

Arduino

Operating System

Windows 10

Flash frequency

80 MHz

PSRAM enabled

no

Upload speed

921600

Description

I expect the following code to output
0
0
0
but the printed output is
0
0
-1306523032

Upon changing the name of the array "times" to something else, the expected output is printed. Is suspect the name "times" is used is some system library in the ESP toolchain. However, in this case I would expect the compilation of the sketch to fail, with an error message like "Redeclaration of symbol 'times', first declared here ...".
Instead, the sketch compiles fine, without any errors or warnings being printed. (Compiler warnings are set to 'all', and verbose output is enabled during compile)

Sketch

#include "time.h"

tm times[2];

void setup() {

  Serial.begin(115200);
  
  for (int i = 0; i < 2; i++){
    times[i].tm_min = 0;
    Serial.println(times[i].tm_min);
  }
  
  Serial.println(times[0].tm_min);
}

void loop() {

}

Debug Message

-

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[Sola85]

A more clear example:

int times[2]; //Bad array
int times2[2]; //Good array

void setup() {

  Serial.begin(115200);
  
  //Working with bad array
  for (int i = 0; i < 2; i++){
    times[i] = 0;
    Serial.println(times[i]);
  }
  Serial.println(times[0]); // <----- produces wrong result

  //Working with good array
  for (int i = 0; i < 2; i++){
    times2[i] = 0;
    Serial.println(times2[i]);
  }
  Serial.println(times2[0]); // this result is correct


  Serial.printf("%p\n", &times[0]);  //Prints 0x40001808
  Serial.printf("%p\n", &times2[0]); //Prints 0x3ffc10a0
}

void loop() {}

Looking at the adresses of both arrays reveals that times2 lies in SRAM (as it should) and times lies in ROM! (according to the memory map at https://www.exploreembedded.com/wiki/images/5/5d/Address_map.JPG).

Compiling this code should probably give an error message.
Furthermore, times is a very likely name for a user to choose. What ever symbol in the ESP core is causing this issue should maybe be renamed.

[chegewara]

Yes, it is strange, but to avoid similat issues you should always use static keyword for global variables.
You will not see the expected warning if for example it is __attribute__((weak)) variable (i didnt see any weak variable, just functions, but who knows).

[atanisoft]

What ever symbol in the ESP core is causing this issue should maybe be renamed.

It's coming from the POSIX API and can not be renamed.

On the ESP32 (and only on the base models) the API itself is implemented in ROM:
https://github.com/espressif/esp-idf/blob/2467aa7f6c177ed040e385657304b0ea413e8133/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld#L8

https://github.com/espressif/esp-idf/blob/2467aa7f6c177ed040e385657304b0ea413e8133/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld#L65

Ref for the function: https://man7.org/linux/man-pages/man2/times.2.html

[Sola85]

Ok, I see.

But is there a reason for why there is no linker error? Building a sketch with a global variable name 'pinMode' fails during compilation, and naming a global variable 'esp_wifi_init' fails during linking. I would naively expect a similar behaviour here. (And as @chegewara pointed out, I too don't think there are any weak variables involved)

[atanisoft]

is there a reason for why there is no linker error?

Most likely due to not including a header that defines the method signature.

Add:

#include <sys/times.h>

to your main file and it should end up with a compilation failure due to type change

[VojtechBartoska]

related issue: #6499. @Sola85 Please take a look there.

[VojtechBartoska]

Hello,

as there was no answer in more than 14 days, I'm closing the issue as expired to keep our backlog manageable.

If it's still needed, please reopen the issue.

Thanks for understanding.