найти дублированные объявленные функции в библиотеке c (отдельные файлы)

Question

Я работаю над встроенным проектом, и я дублирую примерный проект. Не учитывая порядок связывания объектных файлов, я просто помещаю файлы c в произвольном порядке в свой Makefile.

Компиляция и связывание дает executable.elf из 1.9Mb. Ошибок не было, но исполняемый файл не работал.

После долгих поисков, без решения я, наконец, дублирует проект именно, в том числе порядка c файлов (120 из них), и вот я получил executable.elf из 2.2Mb и без каких-либо ошибок. И исполняемый файл работал.

Ничего не изменилось в параметрах компиляции и/или ссылках. Просто изменил порядок, в котором файлы c перечислены в make-файле и, следовательно, порядок объектных файлов во время ссылки.

Я подозреваю, что существует несколько реализаций дубликатов функций с разными телами/размерами. Моя гипотеза заключается в том, что время ссылки компоновщика, без памяти предыдущих действий ссылки, просто выбирает первый, с которым он сталкивается, не поднимая ошибку.

Однако я хотел бы получить эту предоставленную библиотеку (все файлы c, файл lib *.a) и найти дубликаты функций. Поэтому я знаю, в каком порядке я должен предоставить файлы c и, что более важно, почему.

Два вопроса:

1. ли приведенное выше описание, на самом деле потенциальной причиной вопросов?
2. Есть ли другие возможности?
3. Как найти дубликаты функций?

К сожалению, скомпилированный код является патентованным, и детали не могут быть предоставлены в настоящее время.

Компилятор:

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

Цель является:

cortex-m3 

Ваша помощь ценится.

--- EDIT ---

Есть два файла:

1. является список со всеми исходным кодом (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. является Makefile (краткая версия):

   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 $@ 
   

В Makefile ничего не меняю. Изменен только порядок файлов в источнике.mk

Answer 1

Только статические библиотеки (.a или .lib) демонстрируют «разрешение первого совпадения», так что порядок ссылок имеет решающее значение. Начиная с все объектные файлы явно связаны, вы получите ошибку ссылки, если бы были дубликаты символов. Таким образом, такой эффект может иметь только порядок, в котором файлы .a/.lib представлены компоновщику.

Возможно, у вас есть две разные версии библиотеки и связаны между собой в другом порядке?

В корзину binutils GNU toolchain входит инструмент nm для проверки символов в объектных и архивных (библиотечных) файлах.

Альтернативная возможность заключается в том, что исполняемая точка входа чувствительна к порядку привязки на вашей платформе; в этом случае это может быть просто порядок ссылок crt0 (или другой код запуска во время запуска).