Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

крос GDB въпроси
http://mcu-bg.com/mcu_site/viewtopic.php?f=14&t=11508		 Страница 1 от 1
Автор:  ДедоБоре [ Чет Юли 04, 2013 12:01 am ]
Заглавие:  крос GDB въпроси
постановката е следната:
1. АРМ система с вдигната ОС.
gcc, gdb, gdbserver и всички приятели работят нейтив.
локално се копилира тестова програмка и се дебъгва нормално през CLI интерфейса - брейкове, променливи, всичко изглежда ОК.
системата няма графика, паметта не е много, "диска" е USB флашка

2. развойна система със същите версии на ОС, gcc и приятели. но на iх86.
локално всичко си работи нормално - компилира се, дебъгва се

въпрос като за начало:
как, аджеба, да се върже gdb на (2) към gdbserver на (1)?

същия сорс се компилира нейтив и на двете машини. зареждат го нормално и двете програми.
ако просто от (2) се пусне рън на (1) всико минава.
при опит за сет на брейпоинт или инспекция на променлива дава нещо от сорта
Код:
(gdb) b 3
Cannot access memory at address 0x8048460

явно gdb в (2) си мисли в друго адресно пространство (неговото си) и се опитва да ходи по адреси, които не съответстват на същите неща в (1)

четох документацията, ясно е как се прави ремът дебъгинг, но за две еднакви архитектури.
как се прави за различни?
Автор:  palavrov [ Чет Юли 04, 2013 12:32 am ]
Заглавие:  Re: крос GDB въпроси
ДедоБоре написа:
постановката е следната:
1. АРМ система с вдигната ОС.
gcc, gdb, gdbserver и всички приятели работят нейтив.
локално се копилира тестова програмка и се дебъгва нормално през CLI интерфейса - брейкове, променливи, всичко изглежда ОК.
системата няма графика, паметта не е много, "диска" е USB флашка

2. развойна система със същите версии на ОС, gcc и приятели. но на iх86.
локално всичко си работи нормално - компилира се, дебъгва се

въпрос като за начало:
как, аджеба, да се върже gdb на (2) към gdbserver на (1)?

същия сорс се компилира нейтив и на двете машини. зареждат го нормално и двете програми.
ако просто от (2) се пусне рън на (1) всико минава.
при опит за сет на брейпоинт или инспекция на променлива дава нещо от сорта
Код:
(gdb) b 3
Cannot access memory at address 0x8048460

явно gdb в (2) си мисли в друго адресно пространство (неговото си) и се опитва да ходи по адреси, които не съответстват на същите неща в (1)

четох документацията, ясно е как се прави ремът дебъгинг, но за две еднакви архитектури.
как се прави за различни?

Това лесно се решава - трябва ARM ELF файла да е също на х86 машината и да заредиш него за дебъгване а не този който е компилиран за х86. Също така x86 gdb-то трябва да е компилирано с поддръжка и на ARM - което май не е прекомпилирано в нито една голяма х86 дистрибуция доколкото знам - т.е. или си компилираш на х86 gdb-то да поддържа и ARM-a, или за по лесно направо си пускаш gdb от някой cross tool chain.
Тези магии се налагат за да може локалното gdb да зареди вярната дебъг информация, а после самия дебъг да става с gdbserver-а на самото желязо.
target remote <ipaddress> и си готов.
Автор:  ДедоБоре [ Чет Юли 04, 2013 2:46 am ]
Заглавие:  Re: крос GDB въпроси
не мога да компилирам на (1-АРМ) нейтив gdb от по-нова версия. това чудо няма компилиране. тия инструменти са станали невъзможни за билдване :?

а пък gdbserver още configure гърми:
Error: target not supported by gdbserver.

при стар gdbserver na ARM-a (не мога да му разбера точната версия) и по-нов на х86 с едно и също бинари (което си работи на АРМ) се получава:
Код:
Reading symbols from /root/c-test...done.
(gdb) target remote 10.3.1.97:2346
Remote debugging using 10.3.1.97:2346
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
0x00000000 in ?? () from /libexec/ld-elf.so.1
(gdb) b 3
Breakpoint 1 at 0x8518: file c-test.c, line 3.
(gdb) r
The "remote" target does not support "run".  Try "help target" or "continue".
Автор:  palavrov [ Чет Юли 04, 2013 9:20 am ]
Заглавие:  Re: крос GDB въпроси
Порови в гугле за canadian cross - това е когато компилираш всичко на архитектура А, а то трябва да се изпълнява на архитектура Б, пък да компилира/дебъгва за архитектура Ц - при теб Б и Ц са едно и също т.е. ARM. Има доста начини (разбирай скриптове, мейкфалове и т.н.) да си буилднеш туулчейна, просто трябва да видиш кой ще ти пасне. От друга страна не мисля, че е изискване да са ти напълно една и съща версия gdbserver и gdb с което се вързваш към него.
В примера който си дал зареждаш дебъг инфото на хост машината, но не виждам да си заредил на таргета същото бинари.
Т.е. на ARM машината правиш нещо от рода на:
Код:
gdbserver my_arm_app.elf

А на x86:
Код:
$gdb my_arm_app.elf
(gdb) target remote ...
Автор:  miro_atc [ Пет Юли 05, 2013 9:37 am ]
Заглавие:  Re: крос GDB въпроси
сега виждам темата но palavrov общо взето е казал всичко...
Трябва да се компилира арм тулчейн за х86 хост... Това може да е проблем само ако има изисквания точно за опреден тулчейн. Иначе gcc, gdb и т.н. си се компилират без грижа.
Автор:  ДедоБоре [ Пет Юли 05, 2013 11:53 am ]
Заглавие:  Re: крос GDB въпроси
е, ако се компилираше безгрижно, нямаше да се чеша по главата. за интел и Linux (може би) наистина няма проблеми.
в моята ситуация (нейтив компилация на FreeBSD):
Код:
# cd /usr/ports/devel/gdb
# make
===>  gdb-7.6 is only for i386 amd64, while you are running arm.
*** [all] Error code 1

# cd /usr/ports/devel/gdb66/
# make
===>  Building for gdb-6.6_2
...
Configuring in ./gdb
...
configure: error: "*** Gdb does not support native target arm-portbld-freebsd9.1"
gmake[1]: *** [configure-gdb] Error 1


обикновено за взривяване на някой влак е достатъчна някоя бомбичка или обръщане на подходящата стрелка, ама в случая май трябва първо да и построя железопътната линия... вече се ориентирам какво да се портне/допише, но ми липсва скачането по тредове, закачане към процес и прочие "дреболии"

крос-компилация на gdb успявам да направя, обаче нещо не се разбират (1) и (2):
Код:
warning: A handler for the OS ABI "FreeBSD ELF" is not built into this configuration
of GDB.  Attempting to continue with the default arm settings.

Reading symbols from /root/c-test...done.
(gdb) target remote 10.3.1.97:2346
Remote debugging using 10.3.1.97:2346
0x20010e58 in ?? ()
(gdb) r
The "remote" target does not support "run".  Try "help target" or "continue".
(gdb) c
Continuing.
Cannot access memory at address 0x0

Program exited with code 012.
(gdb)


на таргета:
Код:
# gdbserver :2346 c-test
Process c-test created; pid = 7249
Listening on port 2346
Remote debugging from host 10.3.1.19
step1
step2
step3
step4
step5

Child exited with retcode = a

Child exited with status 10
GDBserver exiting


явно двете страни не се разбират напълно, не мога да преценя зали е проблем в диалекта или е по-фундаментален
файла c-test и на двете места е еднакъв:
Код:
# file c-test
c-test: ELF 32-bit LSB executable, ARM, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.1 (901502), not stripped


давайте идеи как да започна борбите?
Автор:  miro_atc [ Пет Юли 05, 2013 12:17 pm ]
Заглавие:  Re: крос GDB въпроси
Дедо, не знам какво точно компилираш, но ако става дума за чисто и стандартно gnu има вече доста тулчейни дето си се компилират. Аз ползвам ягарто и си се компилира как си трябва. Последната му версия е 7.5.1 на gdb но доколкото го следя през годините мисля че няма да е проблем с неговите скриптове да се изкомпилират и баш-баш последните версии на gdb & gcc.
Проблемът обикновено е друг обаче.... от gcc до gcc има разлики, понякога съществени. Най-често стандартните библиотеки правят много грижи, примерно ягарто ползва newlib което си е ОК за малки ембедед неща, но по-вероятно е теб да ти трябва libc lib*... За съжаление от това зависи и компилацията на тулчейна, особено ако си се оженил за нещо не много популярно....

Така де... кво да правиш е въпроса. Аз на твое място бих пробвал различни gdb-та току виж някое тръгнало. Може тук да ти качим готови изпълними файлове за проби, пък ако тръгне ще си бориш компилацията после.
Автор:  palavrov [ Пет Юли 05, 2013 12:29 pm ]
Заглавие:  Re: крос GDB въпроси
Нищо чудно проблема да е точно защото навсякъде се правят нещата под Linux. А под xxxBSD да има някой дребен детайл който като не се направи да прави проблемите които описваш. Не, че е проблем да ги разрешиш, ама вече трети ден се бориш с това, не е ясно още колко време ще отиде - инсталирай си един линукс и да ти е мирна главата. Аз съм под макос (т.е. отдолу е дарвин т.е. бсд) - но за всеки клиент имам по една виртуална машина - един е със убунту 10.04, друг с 12.04, трети с федора, четвърти с някакъв РТОС ... ако трябва да имам един environment който да поддържа всички досега да съм луднал.
Автор:  palavrov [ Пет Юли 05, 2013 12:38 pm ]
Заглавие:  Re: крос GDB въпроси
В момента даже инсталирам още една виртуална машина заради девкита на TI Sitara AM37xxx. На платката има едно малко надписче - "Design by Indians" ... сещай се за какво иде реч. За да изкарам ПДФ-а с документацията за джъмперите които определят от къде да буутва - СД карта, НАНД и т.н. трябва да им инсталирам индианския СДК. Да ама той се запъна на федора виртуалната машина която клиента ми даде и каза че иска убунту 10.04. Какво да се прави - инсталирах я, дали са си оригинално канонично цд. След това пък се запъна че нямам правилния тулчейн - code sourcery от 2008. И за него са дали оригинално цд с 30 дни евалюация. А на мен ми трябва само да видя тъпите джъмпери ... после ще подкарвам всичко с builtroot а той си компилира негов си тулчейн. Заради тъпите индианци няма да си осирам компютъра с хиляда излишни неща - всичко в една виртуална машина и след месец като приключа с тези отива в архива или в коша.
Автор:  ДедоБоре [ Пет Юли 05, 2013 12:47 pm ]
Заглавие:  Re: крос GDB въпроси
е, те сега програмистите си пишат и дебъгват под линукс, щото заплатите и сроковете си вървят...
за релийз обаче проблема е в "отворения" код. всеки (конкурент) има правото да ти поиска сорсовете. и съда ще присъди в негова полза. затова и епъл са стъпили на BSD, не съм им чел внимателно техния лценз, но би трябвало да е в стил "бинарен" с още повече ограничение. М$ пък дори ти ЗАБРАНЯВАТ да правиш ревер-инженеринг с цел да им разбереш алгоритмите и протоколите...

в някои случай е добре да работиш с отворен код, в други - нъцки.
моя случай е императивна необходимост от затворен код.

аз нямам против да пробвам с готов тулченй за FreeBSD 9.x/10.x
има такива за интелска платформа, даже и сам мога да си го компилирам, ако се абстрахирам за момент от GPL3. но за АРМ никой не го пачвал и се налага сам да се боря с тиквата.
Автор:  palavrov [ Пет Юли 05, 2013 12:50 pm ]
Заглавие:  Re: крос GDB въпроси
Ти кода си го остави да е затворен. Ама за дебъгването нищо не пречи да ползваш линукс ...
Автор:  ДедоБоре [ Пет Юли 05, 2013 12:55 pm ]
Заглавие:  Re: крос GDB въпроси
ами пречи, щото архитектурата на ОС е друга. USB е друга концепция, за рутирането пък да не говорим. има и други особености на риболова. ако е прост код без дълбока връзка с реалния свят - става. а да накачулим една камара #ifdef lunux, #ifdef arm ще е четворна работа
Автор:  palavrov [ Пет Юли 05, 2013 2:16 pm ]
Заглавие:  Re: крос GDB въпроси
Не ми схвана идеята - компилирай си на бсд, стартирай на арм, но ако опре за дебъгване - копираш елф файловете на един линукс + сорсовете де, и на него само пускаш дебъгера. Няма нужда да си фрагментираш кода за линукс, бсд, арм и т.н.
Страница 1 от 1 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/