Qtcreator ошибка по удаленной отладке embedded Linux ARM

[VVN]

Уважаемые, Здравствуйте.

Собрал Qt5.6.2 для кросс компиляции в Windows, целевая платформа Linux ARM.
Библиотеки собраны и установлены в release и debug.

В частности плата Orangepi Pc plus, в качестве Linux  Armbian.

Все получилось компилирую в win запускаю на плате.
Запускаться и работает на самой плате, ткже если нажать запуск в Qtcreator и из терминала SmartTTY с пробросом на мою хост машину в Win.

Но что-то не могу победить отладку.

В Qtcretor жму начать отладку на плату программа вроде как устанавливается.
И вроде как начинает работать.
Затем вылетает окно.
Приложение остановлено, так как получило сигнал от операционной системы.
Сигнал: SIGSEGV
Назначение: Segmentation fault

Типовая ошибка если где-то в программе что не так сделал.
Для чистоты эксперимента создал с нуля главное окно, там такая же картина.

По самим отладчикам думал дело в них
Собрал gdb отладчик из исходников от Qtcreator-3.5

Причем собрал gdb-arm-linux-gnueabihf.exe
Там есть момент, кто не в курсе

Код:

В  файле /qtcreator/dist/gdb/Makefile.mingw
Нужно добавить еще одну цель
targets=arm-none-eabi arm-none-linux-gnueabi i686-pc-mingw32 arm-linux-gnueabihf

Тогда соберется еще один отладчик gdb-arm-linux-gnueabihf.exe.
Который в теории подходит, но увы не работает система.

Замучился немного, таки очень непросто было собрать сам Фреймворк для кросс компиляции в win.

Может по отладке кто чего подскажет?
Думаю может не подходит gdb что использую.
Перепробовал разные увы эффекта нет.

[VVN]

Нашел одну не увязку.
У меня стоят два комплекта MinGw

Код:

C:\Qt\MinGw_28_03_2016\bin>"g++.exe" -v
Using built-in specs.
COLLECT_GCC=C:\Qt\MinGw_28_03_2016\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/qt/mingw_28_03_2016/bin/../libexec/gcc/mingw32/4.9.3/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-4.9.3/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32 
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-static --enable-shared --enable-threads 
--with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-libstdcxx-debug --with-tune=generic --enable-nls
Thread model: win32
gcc version 4.9.3 (GCC)

второй

Код:

COLLECT_LTO_WRAPPER=C:/Qt/Qt5.6.2/Tools/mingw492_32/bin/../libexec/gcc/i686-w64-mingw32/4.9.2/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 
--prefix=/mingw32 --with-sysroot=/c/mingw492/i686-492-posix-dwarf-rt_v3-rev1/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ 
--enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes 
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string 
--enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch 
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as 
--with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw492/prerequisites/i686-w64-mingw32-static 
--with-mpfr=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw492/prerequisites/i686-w64-mingw32-static 
--with-isl=/c/mingw492/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw492/prerequisites/i686-w64-mingw32-static 
--enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev
1, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 
-pipe -I/c/mingw492/i686-492-posix-dwarf-rt_v3-rev1/mingw32/opt/include -I/c/mingw492/prerequisites/i686-zlib-static/include 
-I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw492/i686-492-posix-dwarf-rt_v3-rev1/mingw32/opt/include 
-I/c/mingw492/prerequisites/i686-zlib-static/include -I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe 
-L/c/mingw492/i686-492-posix-dwarf-rt_v3-rev1/mingw32/opt/lib -L/c/mingw492/prerequisites/i686-zlib-static/lib 
-L/c/mingw492/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware'
Thread model: posix
gcc version 4.9.2 (i686-posix-dwarf-rev1, Built by MinGW-W64 project)

Момент в следующем у меня в MinGw4.9.3 стоит msys в котором я производил все действия, но путь к компилятору прописан для MinGw4.9.2 которым я все и собираю.
Причем для Фреймворка Linux ARM  MinGw нужен на начальном этапе только для сборки qmake.

Сейчас пересобираю gdb MinGw4.9.2 посмотрю что это мне даст.

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

В одном случае MinGw4.9.3
Target: mingw32
Thread model: win32

В другом случае MinGw4.9.2
Target: i686-w64-mingw32
Thread model: posix

posix вроде как для линукса, но именно этот компилятор идет в комплекте с моим предустановленным Qt5.6.2 на хосте с Win причем я импользуюсь.

Может кто мне объяснить в чем отличия?
И на что это влияет?

[VVN]

Пересобрал MinGw4.9.2 результат нет, вернее он тот же.

Как бы посмотреть отладочную информацию процессе подключения по gdb

[kuzulis]

А попробуй сначала ручками попробовать удаленную отладку сделать из консоли gdb. И если там программа не будет падать, значит пиши баг-репорт.

PS: И вообще, на твоем бы месте я обновил бы QtC на последнюю версию (если у тебя не последняя).

[qate]

posix вроде как для линукса, но именно этот компилятор идет в комплекте с моим предустановленным Qt5.6.2 на хосте с Win причем я импользуюсь.
Может кто мне объяснить в чем отличия?
И на что это влияет?

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

а вообще стоит перебраться на разработку под убунту, раз целевая платформа linux, т.к. думаю мало кто собирает под вендой для linux и ответов не найти

[VVN]

А попробуй сначала ручками попробовать удаленную отладку сделать из консоли gdb. И если там программа не будет падать, значит пиши баг-репорт.

PS: И вообще, на твоем бы месте я обновил бы QtC на последнюю версию (если у тебя не последняя).

Пока не знаю как это делается, нужно почитать доки.
Представляю, что нужно запустить gdb-arm-linux-gnueabihf.exe
Залить программу на тагет и сделать старт.
Если можно пример

На данный момент QtCreator 4.2, с ним работаю.
Но gdb собирал из исходников QtC3.5, почему то от QtC4.2 gdb криво собрался.
Сама сборка всей это кухни занимает много времени где то с час.

[VVN]

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

а вообще стоит перебраться на разработку под убунту, раз целевая платформа linux, т.к. думаю мало кто собирает под вендой для linux и ответов не найти

[/quote]

Почитал по ссылке вроде как на мои дела это влиять не должно, хотя может что не так понял.

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

Мне бы из под винды отладочку запустить

[kuzulis]

Пока не знаю как это делается, нужно почитать доки.

1. Заливаешь твою софтинку на таргет (например через scp или еще как)
2. Запускаешь на таргете gdbserver и подсовываешь ему на вход путь к софтинке которую скопировал, указываешь порт TCP который слушать (гугли как)
3. На хосте запускаешь gdb (наверно gdb-arm-linux-gnueabihf.exe ).
4. В gdb-шной консоли пишешь remote target и указываешь адрес таргета (и дальше гугли).
5. Ставишь бряку, например на main ф-ю (гугли)
6. Запускаешь до бряки и смотриш - упало или нет..
7. Потом можешь запустить до конца (гугли как).
8. Смотришь - упало или нет.
9. Возможно, также в gdb надо будет указать путь к sysroot таргета на твоем хосте, чтобы отладчик подтянуд нужные so-шки.

Там ничо сложного.

[qate]

Подобные инструменты конечно есть в убунте, но с ними придется разбираться а там свои баги.
Мне бы из под винды отладочку запустить

если не разбираться в  целевой операционной системе, то будет ох как сложно и при отладке и при настройке и при вопросах с эксплутации
сидеть в венде через putty очень неудобно
можно всю разработку и отладку сделать в ubunu, а в реальную железяку заливать уже отлаженное приложение )

[VVN]

Там ничо сложного.

Спасибо, так заработало, еще не разбирался с нюансами да и нужно из QtC запускаться.
Самое главное что связка работает.

Теперь сижу и себе думаю что-то не так.

Может я плохо читал, но нигде не видел упоминаний, что нужно в QtC в параметрах GDB что то прописывать.
Прописал только в закладке Устройства (свою целевую плату прописал).

А вопрос в том кто удаленно gdbserver на плате запускать должен.
Думал что все автоматом должно или как?

Пошел в гугл

[VVN]

Поставил QtC4.4.1 результат тот же.
Пробовал играться с разными опциями GDB в параметрах.

Не работает.
Проверил образ на целевую платформу заливается.
Но при начале отладки вываливается окно с дизассемблером и сегментатион фаулт.

Так понимаю проблема с QtCreator

Как-то игрался со сборкой для голого железа для STM32, там тоже была проблема.
После завершения отладки QtC падал но потом нашел решилось (уже не вспомню) какой то галкой в параметрах.
Галки тупо все перебрал.

[kuzulis]

1. В QtC есть меню Window -> Views -> Debugger Log, где нужно поставить галочку и смотеть потом что там не так идет.
2. В QtC в Kit нужно указать sysroot путь также.
3. В *.pro файле приложения добавить install target, и желаемый путь, куда на таргете будет заливаться приложение.
4. Ну и посмотреть еще раз в настройки QtC в RemoteLinux device, на предмет корректного ip, логина, пароля к таргету (жмакнуть кнопку test).
5. И еще, gdb должен быть собран с поддержкой Python (гугли).

[qate]

если креатор падает, то можно посмотреть багрепорты https://bugreports.qt.io/browse/QTCREATORBUG-19160?jql=project%20%3D%20QTCREATORBUG%20AND%20component%20%3D%20Debugger
там есть какие то с удаленной отладкой
если нет такого бага, то написать свой, хотябы ответят баг ли это или както решаемо

[VVN]

2. В QtC в Kit нужно указать sysroot путь также.
3. В *.pro файле приложения добавить install target, и желаемый путь, куда на таргете будет заливаться приложение.
4. Ну и посмотреть еще раз в настройки QtC в RemoteLinux device, на предмет корректного ip, логина, пароля к таргету (жмакнуть кнопку test).
5. И еще, gdb должен быть собран с поддержкой Python (гугли).

Это все сделанно, без поддержки Python отладчик вообще не запустится выругается сто нет Питона.

1. В QtC есть меню Window -> Views -> Debugger Log, где нужно поставить галочку и смотеть потом что там не так идет.

Вот за эту наводку отдельное СПАСИБО немного больше информации стало.

Вот что нашел внутри лога

Код:

dCALL: RUN ENGINE
<68-exec-run
>=thread-group-started,id="i1",pid="6335"
sСоздана группа потоков i1
dПолучено уведомление от pid 6335
>=thread-created,id="1",group-id="i1"
sПоток 1 создан
>=library-loaded,id="/lib/ld-linux-armhf.so.3",target-name="/lib/ld-linux-armhf.so.3",host-name="C:/Qt/LinuxARM/qt5.6.2-arm-linaro-4.8.2/arm-linux-gnueabihf/sysroot/lib/ld-linux-armhf.so.3",symbols-loaded="0",thread-group="i1"
sБиблиотека /lib/ld-linux-armhf.so.3 загружена
>68^running
dNOTE: ENGINE RUN AND INFERIOR RUN OK
sВыполняется.
dState changed from EngineRunRequested(7) to InferiorRunOk(11) [master]
dINFERIOR STARTED
sПриложение запущено
>*running,thread-id="all"
dNOTE: INFERIOR STILL RUNNING IN STATE InferiorRunOk.


>~"\nProgram received signal "
>~"SIGSEGV, Segmentation fault.\n"

>~"0xb6fd9dde in ?? () from C:/Qt/LinuxARM/qt5.6.2-arm-linaro-4.8.2/arm-linux-gnueabihf/sysroot/lib/ld-linux-armhf.so.3\n"

>*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0xb6fd9dde",func="??",args=[],from="C:/Qt/LinuxARM/qt5.6.2-arm-linaro-4.8.2/arm-linux-gnueabihf/sysroot/lib/ld-linux-armhf.so.3"},
thread-id="1",stopped-threads="all",core="3"
dNOTE: INFERIOR SPONTANEOUS STOP
sОстановлено.
dState changed from InferiorRunOk(11) to InferiorStopOk(14) [master]
<69importPlainDumpers off
dHANDLING SIGNAL SIGSEGV
sОстановлено: Segmentation fault (сигнал SIGSEGV).

Получается причина краха lib/ld-linux-armhf.so.3
0xb6fd9dde in ?? () from C:/Qt/LinuxARM/qt5.6.2-arm-linaro-4.8.2/arm-linux-gnueabihf/sysroot/lib/ld-linux-armhf.so.3\n"
Это библиотека из Linux на плате.

Cинхронизировал sysroot не помогло.

Так и что с этим делать.
Интересно к какому пакту она относиться.
Ищем дальше

[VVN]

ld-linux-armhf.so.3 входит в пакет libc6:armhf
Пробовал установить, но у меня он самой последний версии и стоит
Погуглил есть решение

Код:

 ln -s /lib/ld-linux-armhf.so.3 ${D}/lib/ld-linux.so.3

Я правильно понимаю что так делается ссылка на ld-linux.so.3 вместо ld-linux-armhf.so.3

Если это так то, что это даст, судя по логу отладки у меня ld-linux-armhf.so.3 берется из моего sysroot.