[Bug ld/31714] New: Static function pointer

[Senthilkumar.PR at elektrobit dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31714

            Bug ID: 31714
           Summary: Static function pointer
           Product: binutils
           Version: 2.35
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: Senthilkumar.PR at elektrobit dot com
  Target Milestone: ---

Created attachment 15501
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15501&action=edit
Zip folder contains snippet and preprocessed *.c files

Hi,

I am using compiler v10.2 (v10.2_build_b1728_g5963bc8).

GNU ld (GNU Binutils build.sh rev=g5963bc8 s=F1020 -i /opt/freescale Earmv7nGCC
-V release_g5963bc8_build_Fed_Earmv7nGCC (BLD = 1728)) 2.35

I observed some suspicious behavior in Linking.

In my code, I have a static function with the same name in three different
files (Task1.c, Task2.c, and Task3.c). The static function is accessed through
a static volatile function pointer in respective files. The volatile qualifier
is added to avoid optimization. Each file has its own dedicated data section in
memory.

With nxp gcc v10.2 and binutils 2.35, I observed that the data section for all
static variables of Task2 file is initialized properly, but not for the other
files (Task1 and Task3).

As a result, our code crashes when the static function is accessed through the
static function pointer.

Reason: The static function pointer has an invalid address or is "0".

Our observation: When we moved to a higher version of gcc (i.e., v10.3 with
binutils v2.36), this issue is not observed.

Kindly let us know if this issue is already known. If yes, could you please let
us know the right patch version for v2.35? Otherwise, this needs to be fixed in
v2.35.

Upgrading to the v10.3 toolchain is not within our project scope.

I have attached all files and snippets for your reference.

Note: I am working on SRAM; no flash is used, hence no data copy operation.

We used same options for both toolchain version. Except linker option
-specs=nano.specs, this is not used for v10.3 with binutils v2.36


Compiler Option:

-mcpu=cortex-m7 
-mthumb
-mlittle-endian
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-std=c99
-Os
-ggdb3
-Wall
-Wextra
-pedantic
-Wstrict-prototypes
-Wundef
-Wunused
-Werror=implicit-function-declaration
-Wsign-compare
-Wdouble-promotion
-fno-short-enums
-funsigned-char
-funsigned-bitfields
-fomit-frame-pointer
-fno-common
-fstack-usage
-fdump-ipa-all
-c
--sysroot=$(NEWLIB_DIR)
-specs=nano.specs
-specs=nosys.specs

Assembler Option:

-xassembler-with-cpp
-mcpu=cortex-m7
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-mthumb
-c

Linker Option:

--entry=$(ENTRYSYMBOL)
-nostartfiles
-mcpu=cortex-m7
-mthumb
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-mlittle-endian
-ggdb3
-lc
-lm
-lgcc
-specs=nano.specs
-specs=nosys.specs
--sysroot=$(LIB_DIR)


With Regards,

Manjunath Bhavimani

-- 
You are receiving this mail because:
You are on the CC list for the bug.