LINUX.ORG.RU

Артефакты при компиляции под Linux

 ,


0

1

Наблюдаю занимательный баг, не представляю в какую сторону копать.
Дано: девайс STM32F779I-EVAL. В качестве Hello world хочу скомпилировать стандартный проект с GUI, который предлагается TouchGFX (поддерживается только на Windows).
1. Запускаю под виртуалкой с виндой TouchGFX, генерирую исходники. Собираю под той же виртуалкой с помощью arm-none-eabi-gcc-6.3.1, заливаю на девайс - все отлично.
2. Копирую исходники из виртуалки на Linux, собираю с помощью arm-none-eabi-gcc-8.2.0 (пробовал так же 6.4.0), заливаю на девайс (для чистоты эксперимента тем же виндовым st-link, который был в п.1) и получаю вот такой артефакт (нарушение цветов и некоторая «рябь» на экране).
Есть идеи в чем может крыться причина? Makefile на обеих платформах используется один и тот же, отличается только версия компилятора.


Ответ на: комментарий от CYB3R

Ок, но а в чем собственно идея? Сравнил: отличаются. Но мне все ещё непонятно в какую сторону копать чтобы исправить это.

maked0n
() автор топика
Ответ на: комментарий от maked0n

Ты не бинарники сравнивай, а дизассемблер той части кода, которая за вывод картинки отвечает!

Наверняка из-за оптимизации какая-нибудь хрень вылезла.

anonymous
()
Ответ на: комментарий от maked0n

Компилируй на OS 3.0 птица де и увидишь разницу , дистрибутив это душа и если она хреновая то и выход получишь хреновый

anonymous
()
Ответ на: комментарий от maked0n

Всё не так просто, как я ожидал. По видимому, нет другого способа выяснить, кроме как отсекать всё больше и больше кусков кода в поиске той части, которая вызывает глюк.

i-rinat ★★★★★
()
Ответ на: комментарий от maked0n

в какую сторону копать

Сам код пиши, вестимо! Ну или хотя бы чужой быдлокод до нормального уровня доведи.

anonymous
()

Скорее всего в Makefil'e есть часть, которая зависит от ОСи, проверь. А лучше - сверь все obj файлы и найди чё отличается.

А так же проверь дизасемблированный код, как советовали выше.

SL_RU ★★★★
()

Возьми тулчейн отсюда и собери на линуксе, а потом уже копай. Хотя очень вероятно что у тебя все заработает нормально.

И если ты на самом деле гентушник и собирал компилятор из ёбилдов, то ты ССЗБ

Алсо линаровский пробовал?

anonymous
()
Ответ на: комментарий от anonymous

Имел в виду проект собрать, а не тулчейн по тем исходникам, а то ты снова все сломаешь.

anonymous
()

Если -O0 не помогло, то тогда вероятно дело в макросах или в include-файлах самого gcc (может что-то пролезло из системных, бывает).

Я бы посмотрел разницу в ассемблерном коде (-save-temps) отвечающим за инициализацию вывода на матрицу. А после понять из-за чего разница.

Более сложный путь = повозиться с исходниками после препроцессора. Например, для начала получить выхлоп препроцессора от arm-none-eabi-gcc-6.3.1 под виндой и собрать бинарник посредством arm-none-eabi-gcc-8.2.0.

Либо прогнать через clang-format и посмотреть diff.

Deleted
()
Ответ на: комментарий от anonymous

Эклипсовский не помог, линаровский попробую.

И если ты на самом деле гентушник и собирал компилятор из ёбилдов, то ты ССЗБ

именно так и я сделал :)

Похоже, что дело в линуксовом линковщике: взял объектники скомпилированные в линуксе и слинковал их в винде. После этого артефактов не наблюдаю.

maked0n
() автор топика

Используется следующий скрипт линковщика (что на винде, что на линуксе):

_STACKSIZE = 1024;
_HEAPSIZE = 512;

MEMORY
{
    CODE (rx)   : ORIGIN = 0x08000000, LENGTH = 2048K
    RAM (rw)    : ORIGIN = 0x20000000, LENGTH = 496K
    QUADSPI (r) : ORIGIN = 0x90000000, LENGTH = 64M
}

/* Section Definitions */

ENTRY(ResetISR)

SECTIONS
{
	/* first section is .text which is used for code */
	.text :
	{
		CREATE_OBJECT_SYMBOLS
		KEEP(*(.isr_vectors))
		*(.text .text.*)
		*(.gnu.linkonce.t.*)
		*(.glue_7t) *(.glue_7) *(.vfp11_veneer)
		KEEP(*(.fini))
		*(.gcc_except_table)
		. = ALIGN(0x4);
	} >CODE = 0
	. = ALIGN(4);

	/* .ctors .dtors are used for c++ constructors/destructors */
	
	.ctors :
	{
		PROVIDE(__ctors_start__ = .);
		KEEP(*(SORT(.ctors.*)))
		KEEP(*(.ctors))
		PROVIDE(__ctors_end__ = .);
	} >CODE

	.dtors :
	{
		PROVIDE(__dtors_start__ = .); 
		KEEP(*(SORT(.dtors.*)))
		KEEP(*(.dtors))
		PROVIDE(__dtors_end__ = .);
	} >CODE
	
	/* .rodata section which is used for read-only data (constants) */

	.rodata :
	{
		*(.rodata .rodata.*)
		*(.gnu.linkonce.r.*)
	} >CODE
	. = ALIGN(4);

	.init_array :
	{
		*(.init)
        *(.fini)
		PROVIDE_HIDDEN (__preinit_array_start = .);
		KEEP (*(.preinit_array))
		PROVIDE_HIDDEN (__preinit_array_end = .);
		PROVIDE_HIDDEN (__init_array_start = .);
		KEEP (*(SORT(.init_array.*)))
		KEEP (*(.init_array))
		PROVIDE_HIDDEN (__init_array_end = .);
		PROVIDE_HIDDEN (__fini_array_start = .);
		KEEP (*(.fini_array))
		KEEP (*(SORT(.fini_array.*)))
		PROVIDE_HIDDEN (__fini_array_end = .);
	} >CODE

	. = ALIGN(4);

	/* .ARM.exidx is sorted, so has to go in its own output section.  */
	__exidx_start = .;
	.ARM.exidx :
	{
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
	} >CODE
	__exidx_end = .;


 	_etext = .;
	PROVIDE (etext = .);

	.data : AT (_etext)
	{
		__data_start = .;
		*(.data .data.*)
		*(.gnu.linkonce.d.*)
		SORT(CONSTRUCTORS)
		. = ALIGN(4);
		*(.fastrun .fastrun.*)
	} >RAM
	. = ALIGN(4);
	
	_edata = .;
	PROVIDE (edata = .);

	/* .bss section which is used for uninitialized data */

	.bss :
	{
		__bss_start = .;
		__bss_start__ = .;
		*(.bss .bss.*)
		*(.gnu.linkonce.b.*)
		*(COMMON)
		. = ALIGN(4);
	} >RAM
	__bss_end__ = .;
	
	_end = .;
	PROVIDE(end = .);

	/* .heap section which is used for memory allocation */
	
	.heap (NOLOAD) :
	{
		__heap_start__ = .;
		*(.heap)
		. = MAX(__heap_start__ + _HEAPSIZE , .);
	} >RAM
	__heap_end__ = __heap_start__ + SIZEOF(.heap);
	
	/* .stack section - user mode stack */
	
	.stack (__heap_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		. = ALIGN(8);
		__stack_start__ = .;
		*(.stack)
		. = ALIGN(8);
		. = MAX(__stack_start__ + _STACKSIZE , .);
	} >RAM
	__stack_end__ = __stack_start__ + SIZEOF(.stack);

	/* Stabs debugging sections.  */
	.stab          0 : { *(.stab) }
	.stabstr       0 : { *(.stabstr) }
	.stab.excl     0 : { *(.stab.excl) }
	.stab.exclstr  0 : { *(.stab.exclstr) }
	.stab.index    0 : { *(.stab.index) }
	.stab.indexstr 0 : { *(.stab.indexstr) }
	.comment       0 : { *(.comment) }
	/* DWARF debug sections.
		Symbols in the DWARF debugging sections are relative to the beginning
		of the section so we begin them at 0.  */
	/* DWARF 1 */
	.debug          0 : { *(.debug) }
	.line           0 : { *(.line) }
	/* GNU DWARF 1 extensions */
	.debug_srcinfo  0 : { *(.debug_srcinfo) }
	.debug_sfnames  0 : { *(.debug_sfnames) }
	/* DWARF 1.1 and DWARF 2 */
	.debug_aranges  0 : { *(.debug_aranges) }
	.debug_pubnames 0 : { *(.debug_pubnames) }
	/* DWARF 2 */
	.debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
	.debug_abbrev   0 : { *(.debug_abbrev) }
	.debug_line     0 : { *(.debug_line) }
	.debug_frame    0 : { *(.debug_frame) }
	.debug_str      0 : { *(.debug_str) }
	.debug_loc      0 : { *(.debug_loc) }
	.debug_macinfo  0 : { *(.debug_macinfo) }
	/* SGI/MIPS DWARF 2 extensions */
	.debug_weaknames 0 : { *(.debug_weaknames) }
	.debug_funcnames 0 : { *(.debug_funcnames) }
	.debug_typenames 0 : { *(.debug_typenames) }
	.debug_varnames  0 : { *(.debug_varnames) }	

	ExtFlashSection :
	{
		*(ExtFlashSection ExtFlashSection.*)
		*(.gnu.linkonce.r.*)
        . = ALIGN(0x4);
	} >QUADSPI
}

 __valid_user_code_checksum = 0 - (__stack_end__ + ResetISR + 1 + NMI_Handler + 1 + HardFault_Handler + 1 + MemManage_Handler + 1 + BusFault_Handler + 1 + UsageFault_Handler + 1);

maked0n
() автор топика
Ответ на: комментарий от SL_RU

Скорее всего в Makefil'e есть часть, которая зависит от ОСи, проверь.

Есть, но она не аффектит сборку, отвечает исключительно за flashing. Части, ответственные за компиляцию и линковку, платформонезависимые.

maked0n
() автор топика
Ответ на: комментарий от maked0n

Похоже, что дело в линуксовом линковщике: взял объектники скомпилированные в линуксе и слинковал их в винде. После этого артефактов не наблюдаю.

Сравнить в чём отличие полученных бинарников, при том, что они из одних и тех же объектников?

Deleted
()
Ответ на: комментарий от maked0n

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

Стопудово, проблема кроется в какой-нибудь «быдлобиблиотеке», которую ты тянешь!

Не надо так делать. Пиши все свое. Либо тщательно выверяй чужой код, если самому лень писать. Выкидывай мусор, причесывай...

anonymous
()

Могу предположить, что в коде есть UB, который может проявляться не только от разных версий компилятора. Нечто подобное видел на ARM при операциях с невыровненными словами.

Elyas ★★★★★
()

Пардон, я тут потерялся во флейме. Проблему удалось побороть или нет? Если да, то как?

Deleted
()
Ответ на: комментарий от Deleted

К сожалению, пока что нет, еще работаю над этим. Пробовал разные тулчейны, пробовал брать MinGWшный newlib с виртуалки: ничего не помогает. Видимо действительно единственный вариант - сравнивать дизассемблированный код посекционно. Правда я пока что не понимаю чего смогу этим добиться.
В качестве временного workaround линкую в виртуалке, работа не ждет :(

maked0n
() автор топика
Последнее исправление: maked0n (всего исправлений: 1)
Ответ на: комментарий от maked0n

За два дня мог бы уже хотя бы на уровне «blink» освоить микроконтроллер!

Стащи наиболее подходящие тебе файлы линкера и стартап, напиши Makefile и пиши уже код...

За один вечер (часа 4) можно с нуля уже помигать светодиодиком было и по UART подключить через преобразователь к компьютеру! А дальше все как по маслу пойдет.

anonymous
()
Ответ на: комментарий от anonymous

За два дня мог бы уже хотя бы на уровне «blink» освоить микроконтроллер!

За один вечер (часа 4) можно с нуля уже помигать светодиодиком было и по UART подключить через преобразователь к компьютеру!

Не понимаю при чем тут это. «Светодиодиком моргать» у меня получается. По маслу, к сожалению, не пошло.

maked0n
() автор топика
Ответ на: комментарий от maked0n

Ля да собери объектники одним компилером на линухе и слинкуй два файла - на вантузи и на лине. И выложи их на файлообменник кой-нить.

А артефакт 146% что смещение адреса внутри функции вывода изображения, причем в той части что выводит нижний слой/склеивает их - текст и кнопка выведены нормально.

anonymous
()
Ответ на: комментарий от maked0n

По маслу, к сожалению, не пошло.

Потому что ты сразу захотел GUI!

GUI на микроконтроллере — штука сложная. Ты для начала разберись, как заливать цветом экран. Потом напиши функции построения графических примитивов. Добавь шрифты (благо, их самому писать не нужно - на просторах интернетов полно)... В итоге за полгодика осилишь GUI.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.