постановката е следната:
1. АРМ система с вдигната ОС.
gcc, gdb, gdbserver и всички приятели работят нейтив.
локално се копилира тестова програмка и се дебъгва нормално през CLI интерфейса - брейкове, променливи, всичко изглежда ОК.
системата няма графика, паметта не е много, "диска" е USB флашка

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

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

същия сорс се компилира нейтив и на двете машини. зареждат го нормално и двете програми.
ако просто от (2) се пусне рън на (1) всико минава.
при опит за сет на брейпоинт или инспекция на променлива дава нещо от сорта

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

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

Това лесно се решава - трябва ARM ELF файла да е също на х86 машината и да заредиш него за дебъгване а не този който е компилиран за х86. Също така x86 gdb-то трябва да е компилирано с поддръжка и на ARM - което май не е прекомпилирано в нито една голяма х86 дистрибуция доколкото знам - т.е. или си компилираш на х86 gdb-то да поддържа и ARM-a, или за по лесно направо си пускаш gdb от някой cross tool chain.
Тези магии се налагат за да може локалното gdb да зареди вярната дебъг информация, а после самия дебъг да става с gdbserver-а на самото желязо.
target remote <ipaddress> и си готов.

не мога да компилирам на (1-АРМ) нейтив gdb от по-нова версия. това чудо няма компилиране. тия инструменти са станали невъзможни за билдване

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

при стар gdbserver na ARM-a (не мога да му разбера точната версия) и по-нов на х86 с едно и също бинари (което си работи на АРМ) се получава:

Порови в гугле за canadian cross - това е когато компилираш всичко на архитектура А, а то трябва да се изпълнява на архитектура Б, пък да компилира/дебъгва за архитектура Ц - при теб Б и Ц са едно и също т.е. ARM. Има доста начини (разбирай скриптове, мейкфалове и т.н.) да си буилднеш туулчейна, просто трябва да видиш кой ще ти пасне. От друга страна не мисля, че е изискване да са ти напълно една и съща версия gdbserver и gdb с което се вързваш към него.
В примера който си дал зареждаш дебъг инфото на хост машината, но не виждам да си заредил на таргета същото бинари.
Т.е. на ARM машината правиш нещо от рода на:

А на x86:

сега виждам темата но palavrov общо взето е казал всичко...
Трябва да се компилира арм тулчейн за х86 хост... Това може да е проблем само ако има изисквания точно за опреден тулчейн. Иначе gcc, gdb и т.н. си се компилират без грижа.

е, ако се компилираше безгрижно, нямаше да се чеша по главата. за интел и Linux (може би) наистина няма проблеми.
в моята ситуация (нейтив компилация на FreeBSD):

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

крос-компилация на gdb успявам да направя, обаче нещо не се разбират (1) и (2):


на таргета:


явно двете страни не се разбират напълно, не мога да преценя зали е проблем в диалекта или е по-фундаментален
файла c-test и на двете места е еднакъв:


давайте идеи как да започна борбите?

Дедо, не знам какво точно компилираш, но ако става дума за чисто и стандартно gnu има вече доста тулчейни дето си се компилират. Аз ползвам ягарто и си се компилира как си трябва. Последната му версия е 7.5.1 на gdb но доколкото го следя през годините мисля че няма да е проблем с неговите скриптове да се изкомпилират и баш-баш последните версии на gdb & gcc.
Проблемът обикновено е друг обаче.... от gcc до gcc има разлики, понякога съществени. Най-често стандартните библиотеки правят много грижи, примерно ягарто ползва newlib което си е ОК за малки ембедед неща, но по-вероятно е теб да ти трябва libc lib*... За съжаление от това зависи и компилацията на тулчейна, особено ако си се оженил за нещо не много популярно....

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

Нищо чудно проблема да е точно защото навсякъде се правят нещата под Linux. А под xxxBSD да има някой дребен детайл който като не се направи да прави проблемите които описваш. Не, че е проблем да ги разрешиш, ама вече трети ден се бориш с това, не е ясно още колко време ще отиде - инсталирай си един линукс и да ти е мирна главата. Аз съм под макос (т.е. отдолу е дарвин т.е. бсд) - но за всеки клиент имам по една виртуална машина - един е със убунту 10.04, друг с 12.04, трети с федора, четвърти с някакъв РТОС ... ако трябва да имам един environment който да поддържа всички досега да съм луднал.

В момента даже инсталирам още една виртуална машина заради девкита на TI Sitara AM37xxx. На платката има едно малко надписче - "Design by Indians" ... сещай се за какво иде реч. За да изкарам ПДФ-а с документацията за джъмперите които определят от къде да буутва - СД карта, НАНД и т.н. трябва да им инсталирам индианския СДК. Да ама той се запъна на федора виртуалната машина която клиента ми даде и каза че иска убунту 10.04. Какво да се прави - инсталирах я, дали са си оригинално канонично цд. След това пък се запъна че нямам правилния тулчейн - code sourcery от 2008. И за него са дали оригинално цд с 30 дни евалюация. А на мен ми трябва само да видя тъпите джъмпери ... после ще подкарвам всичко с builtroot а той си компилира негов си тулчейн. Заради тъпите индианци няма да си осирам компютъра с хиляда излишни неща - всичко в една виртуална машина и след месец като приключа с тези отива в архива или в коша.

е, те сега програмистите си пишат и дебъгват под линукс, щото заплатите и сроковете си вървят...
за релийз обаче проблема е в "отворения" код. всеки (конкурент) има правото да ти поиска сорсовете. и съда ще присъди в негова полза. затова и епъл са стъпили на BSD, не съм им чел внимателно техния лценз, но би трябвало да е в стил "бинарен" с още повече ограничение. М$ пък дори ти ЗАБРАНЯВАТ да правиш ревер-инженеринг с цел да им разбереш алгоритмите и протоколите...

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

аз нямам против да пробвам с готов тулченй за FreeBSD 9.x/10.x
има такива за интелска платформа, даже и сам мога да си го компилирам, ако се абстрахирам за момент от GPL3. но за АРМ никой не го пачвал и се налага сам да се боря с тиквата.

Ти кода си го остави да е затворен. Ама за дебъгването нищо не пречи да ползваш линукс ...

ами пречи, щото архитектурата на ОС е друга. USB е друга концепция, за рутирането пък да не говорим. има и други особености на риболова. ако е прост код без дълбока връзка с реалния свят - става. а да накачулим една камара #ifdef lunux, #ifdef arm ще е четворна работа

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