CODEWITHSUNDEEP
cgcclinkerembedded
Robert
Robert

Reputation: 11

find duplicate declared functions in c library (single files)

I'm working on an embedded project and I am duplicating a sample project. Not taking the linking order of the object files into account, I just put the c files in a random order in my Makefile.

Compiling and linking yields an executable.elf of 1.9Mb. No errors were generated but the executable didn't work.

After a long search with no solution I finally duplicated the project exactly, including the order of the c files (120 of them) and behold I got an executable.elf of 2.2Mb and no errors. AND the executable worked.

Nothing changed in compile-options and/or linking-options. Just changed the order in which the c files are listed in the makefile, and therefore the order of the object files at link time.

I suspect that there are multiple duplicate function implementations with different bodies/sizes. My hypothesis is that link time the linker, with no memory of previous link actions, just picks the first one it encounters without raising an error.

However I would like to get a hold on this provided library (all single c files, no lib *.a file) and find the duplicate function implementations. So I know in which order I should provide the c files and more importantly, why.

Two questions:

  1. Is the description above, indeed a potential cause of the issues?
  2. Are there other possibilities?
  3. How to find the duplicate function implementations?

Unfortunately, the code being compiled is proprietary and details cannot be shared at this time.

Compiler is:

 arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]

Target is:

 cortex-m3

Your help is appreciated.

--- EDIT ---

There are two files:

  1. is the list with all the source code (source.mk):

     C_FILES_SRC  = $(SDK_DIR)/file001.c
 C_FILES_SRC += $(SDK_DIR)/file002.c
 C_FILES_SRC += $(SDK_DIR)/ .....
     |
 C_FILES_SRC += $(APPL_DIR)/file121.c
 C_FILES_SRC += $(APPL_DIR)/file122.c

  2. is the Makefile (short version):

    include source.mk
CFLAGS = xxxxx
# create objects
%.o: %.c
    $(GCC) $(CFLAGS) -MMD -MP -MF($(@:%.o=%.d) -o $@ -c $<

# link it all together
executable.elf
    $(GCC) $(MAIN_CFLAGS) $(LINK_SCRIPTS) -Xlinker --gc-sections $(LIBS_DIR) $(EXTRA_LINK_FLAGS) $(SPECS) -o $@ $(OBJS) $(LIBS)
    $(SIZE) --format=berkeley $@

In the Makefile I change nothing. Only changed the order of files in source.mk

Upvotes: 1

Views: 360

Answers (1)

Clifford
Clifford

Reputation: 93554

Only static libraries (.a or .lib) exhibit "first match resolution" such that link order was critical. Since all object files are explicitly linked, you'd get a link error if there were duplicate symbols. So only the order the the .a/.lib files are presented to the linker could have that effect.

Perhaps you have two different versions of a library and are linking both in a different order?

The GNU toolchain's binutils includes the nm tool for examining symbols in object and archive (library) files.

An alternative possibility is that the executable entry point is sensitive to link order on your platform; in which case it may just be the link order of crt0 (or other run-time start-up code).

Upvotes: 1

Related Questions