ПРОБЛЕМА
Для определенного .obj
мой компилятор «переключает» значение байта между сборками, даже если я не меняю что-нибудь. Это всегда одна и та же позиция байта и всегда одно из двух значений: 0x00
или же 0x80
ФОН
Я использую компилятор QNX C ++; его gcc
на основе так просто думать об этом как gcc
,
мой make
команда:
C:\make421.exe all --trace --debug=vjm --jobs=16 --output-sync=recurse --print-directory --print-data-base
make
Правило для этого объекта перечисляет файлы, которые ВСЕ содержатся в моей рабочей папке верхнего уровня.
Зависит только от одного .cpp
файл, который не меняется — я делаю Beyond Compare на весь HMI_FORGF
папка, в которой находятся артефакты — и я также проверяю другие папки, в которых находятся библиотеки.
АБСОЛЮТНО НИЧЕГО НЕ ИЗМЕНЯЕТСЯ!
ВОПРОС
Почему один байт переключается без изменений в. , , ЧТО-НИБУДЬ?
Да, я также спрошу QNX, но хотел посмотреть, испытывал ли кто-нибудь подобное.
ОБНОВИТЬ
Я сделал различие objdump -xSsDg
вывод, но его размер превышает 100 МБ, поэтому не могу загрузить его (если кто-нибудь знает сайт для размещения, дайте мне знать).
В diff есть два разных раздела:
Первый раздел, слева
Contents of section .ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE:
0000 00000000 00000000 ........
Первый раздел, справа
Contents of section .ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE:
0000 00000000 00000080 ........
Второй раздел, слева
00000000 <.ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE>:
...
0: R_ARM_PREL31 .text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
0: R_ARM_NONE __aeabi_unwind_cpp_pr1
4: R_ARM_PREL31 .ARM.extab.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
Второй раздел, справа:
00000000 <.ARM.exidx.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE>:
0: 00000000 andeq r0, r0, r0
0: R_ARM_PREL31 .text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
0: R_ARM_NONE __aeabi_unwind_cpp_pr1
4: 80000000 andhi r0, r0, r0
4: R_ARM_PREL31 .ARM.extab.text._ZN5QHashI7QStringiE11deleteNode2EPN9QHashData4NodeE
Задача ещё не решена.
Других решений пока нет …