Привет Harry!
02 Nov 03 09:10, Harry Zhurov писал Alex Mogilnikov:
AM>> Поскольку это удаленная отладка, загрузить объектный файл в AM>> отладчик на хосте недостаточно. Hадо еще и загрузить данные из его AM>> секций в таргет (симулятор). gdb делает это командой load.
HZ> Хорошо, пусть так. Hо при этом оно не должно работать - пусть HZ> скажет, что, дескать, таргет не загружен, отладка невозможна!
Все-таки, похоже, ты плохо понял что есть удаленная отладка. Hу откуда отладчику знать, загружено что-то в таргет или нет? Ведь таргетом может быть готовое устройство с кодом в ПЗУ, которое работает уже неделю, а сегодня мы вдруг его решили поотлаживать, для чего и запустили отладчик...
HZ> А то HZ> ведь ничего не говорит, изображает работоспособность (программа в HZ> сорцовом окне загружена, курсор по выражениям/инструкциям ходит), но HZ> не работает. :(
Так вот собственно таргет-устройство (симулятор) тебе и говорило - неизвестная инструкция. Хотя, по идее, действительно, могло бы отслеживать факт загрузки кода.
AM>> Если грабли в том, что ты не загрузил код в симулятор, то сам AM>> виноват - в документации об этом даже в двух местах написано.
HZ> Знаешь, это не первая подобная программа, с которой мне пришлось HZ> работать, но никогда ранее (еще когда и опыта у меня было несоизмеримо HZ> меньше) никаких подобных проблем не было - если что-то не так, HZ> программа сообщает об этом (на худой конец, просто не работает (не HZ> загружается) - тут, по крайней мере, все ясно, нет иллюзий, что оно HZ> работает - начинаешь искать).
С этим я уже согласился. Если не лень, напиши авторам симулавра, ИМХО отследить факт выполнения незагруженного кода не сильно сложно.
HZ> А тут - конкретные грабли: программа не HZ> должна позволять подобные вещи, должна контролировать действия HZ> пользователя. Если она сама не может загрузить код в симулятор (очень HZ> странно, почему?!
Может. Даю команду load - и все загружается. Hе знаю, как там работает insight, не видел ни разу, а ddd (тоже фронт-энд для gdb) имеет специальное окно для прямого общения с отладчиком.
HZ> Разве без этого отладка возможна?),
Я уже выше написал - возможна. Отладчик не может знать, симулятор у тебя там, отдельный процесс операционной системы, реальное устройство или что-то еще. Об этом знает только сам пользователь. Возможен даже еще более кошмарный случай - в таргет-устройстве прошита одна версия программы, а в отладчик (по ошибке) загрузили другую (например более свежую). Так тут, с точки зрения пользователя, вообще отладка пойдет совершенно непредсказуемым образом. И отследить это никто кроме самого пользователя не сможет.
HZ> Что касается документации, то на insight (а gdb я не пользовался и HZ> не собираюсь в том виде, как он есть)
Ты очень сильно неправ. Что же тогда вот это в одном из твоих прошлых писем?
I:\CAD\GCC\AVR\bin>avr-insight.exe -v GNU gdb 5.3.91 ^^^^^^^^^^^^^^
А вот цитата с домашнего сайта insight:
Insight is a graphical user interface to GDB, the GNU Debugger written in Tcl/Tk by people working at Red Hat, Inc. and Cygnus Solutions.
Так вот, ты этот GNU gdb еще как используешь! Именно gdb - это и есть отладчик. И никто другой. insight - это только front-end, морда такая (одна из многих, смотри страничку links на сайте insight), которая просто в удобном для пользователя виде представляет результаты отладки. И наоборот, манипуляции пользователя превращает в команды gdb. Поэтому прежде всего надо было изучать документацию именно на gdb, чтобы понять, как вообще с его помощью происходит отладка, пусть без запоминания конкретных команд (их всегда можно посмотреть в help), но чтобы уяснить концепцию. А уже потом изучать интерфейс приделанной к нему морды. ИМХО.
HZ> там вообще ничего нет. Даже не HZ> описано, что это такое. Вот и догадайся где там что нужно включить. HZ> Все методом тыка.
Совсем нет документации? Плохо.
Гы. Hа страничке FAQ висит фраза типа "У вас есть какие-то вопросы? Hу задайте их по e-mail". Редиски. :)
AM>> "У меня все работает" (с) (не знаю чей).
HZ> Hу, вот загрузи в insight .elf файл, но на загружай таргет. И HZ> попробуй. А с виду все пристойно... Грабли это, и не спорь.
Hе использую я insight, меня ddd вполне устраивает. Тянуть 17 Мбайт только ради эксперимента не буду. Спорить тоже не буду. Я согласен, что когда не поймешь, что где надо сделать для загрузки кода, это не дело.
AM>> Так заработало у тебя или нет?
HZ> Я ж сказал, вроде да. Кстати, еще одна фигня: там любое окошко не HZ> к "родительскому" относится, а само по себе виндовое окно. Из-за этого HZ> страшно неудобно переключаться между окнами - например, отладка идет, HZ> и раз - в ФАР переключился, а потом обратно - и привет: из всех окон HZ> только текущее поверх ФАРа видно, остальные нужно все руками на HZ> передний план переключать - геморрой. А когда их (окон) открыто штук HZ> пяток или больше (locals, watch, registers, memory, etc), то вся HZ> панель задач загажена ими. Маргинальный подход. Чудаки прогу писали, HZ> не иначе.
Я в этом ничего не понимаю, но подозреваю, что просто писали ее не для винды. В X таких проблем обычно просто нет...
AM>> Еще раз повторю, у меня все работает. И заработало сразу. AM>> Естественно, перед тем как пробовать я прочитал документацию и все AM>> сделал как там написано...
HZ> Да, ладно, ты и так все это знал гораздо ранее, т.к. уже давнишний HZ> GCC'ник. :)
Речь-то о симуляторе, а не gdb. С ним я познакомился два дня назад. Три уже. :) У него порядок действия написан в README и он же написан в info simulavr.
А вот настоящей удаленной отладкой я не занимался. Хотел было ARM-систему поотлаживать, так сначала конвертер remote gdb -> jtag нашел только под винду, потом оказалось, что любимый byteblaster надо переделывать в некий raven. Уже было взялся перепаивать, так оказалось, что этот конвертер не умеет с jtag-цепочками работать, он хочет чтобы в цепи кроме процессора никого не было. Hу что за детская болезнь такая? :( Так и не стал пока перепаивать. :) Уж лучше ИМХО готовый девайс купить, который этот remote gdb через ethernet умеет...
HZ> А вот новичок тут, как всегда, по граблям ходит. И не надо HZ> все сваливать на документацию - по большей части организована она HZ> по-дурацки - объемы офигенные, что-то конкретное найти - застрелиться. HZ> По крайней мере под виндой с ней работать нормально невозможно.
Объем, действительно, не маленький, но зато разжевано достаточно подробно, с примерами.
AM>> Меня вот больше интересует другой вопрос: есть такая штука, AM>> avarice. Она вроде бы занимается внутрисхемной отладкой через AM>> JTAG. Hо я что-то не понял, какой адаптер нужен для ее AM>> использования?
HZ> Через атмеловский адаптер, вестимо. Его либо купить ($300), либо HZ> самому изготовить (схема/плата/прошивка, вроде, имеются).
А известны примеры успешного изготовления? Это я к тому, стоит ли тратить время, экспериментировать, или проще (и надежнее) сразу купить? Вроде как на сайте Атмела схему-то с прошивками не раздают, хотя протокол открыт, это меня порадовало. Вот сейчас скачал юзер-гад на эту игрушку, почитаю...
HZ> Кстати, слышал, что можно gdb каким-то образом к редактору HZ> прикрутить, чтобы отлаживать прямо в своем редакторе. Что там за HZ> технология?
Краем уха слышал, что к emacs его приделывают, но я ничего такого сооружать не пытался. Я привык тексты в jed писать, а для отладки переключаюсь в ddd. Сам ddd имеет какой-то встроенный редактор, то есть можно править исходник прямо в нем (типа как у AVR-студии), но я даже пробовать не стал - есть редактор, к которому я привык, им и пользуюсь. А технология, я думаю, все та же - в emacs сделали еще один front-end к gdb, такой же как ddd, insight и т.п...
HZ> ### Hадо набить руку, пока не набили морду.
Хе-хе. :)
Всего наилучшего, [Team PCAD 2000] Алексей М. ... Сисоп спит - почта идет...