ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
13 июля
471122 Топик полностью
fk0, легенда (06.12.2013 15:06 - 15:14, просмотров: 99) ответил ig_z на Вот как раз использование функции "поиск" - последнее(предпоследнее) к чему нужно обращаться при анализе трассы. И уж тем более не грепом файндом. Использование пары TT_EN и TT_EX это проблема С. В С++ этого естественно нет и допустить ошибку
Не понял, как C++ позволяет это. Перегрузку operator() не применишь же к обычной функции. А всё заворачивать в спец-классы нереально. Да и с аргументами не пойми как быть. Особенно с va_list. Трассировка без записи аргументов попросту не нужна. Про автоматически генерённый код -- это я к тому, что сложно сделать, чтоб он корректно автоматически генеровался. Может быть, можно сделать такую штуку: gcc умеет -finstrument-functions. И дальше поступить вот таким образом, что в __cyg_profile_func_enter сохранять регистры в которых могут быть аргументы и вершину стека, а в exit сохранять регистры в которых возврат результата и опять же вершину стека. И нужен механизм разобрать потом сохранённое и с определённой вероятностью (увы) вытащить значения аргументов и результатов. И объём информации очень большой, тяжко. Вот как бы пример такого http://linuxgazette.net/151/melinte.html Вот ещё интересную штуку нагуглил, но боюсь столько брейкпоинтов нереально поставить нигде: http://web.archive …-gnu-project-debugger/ А это касается текстового редактора -- по моему и нет никаких волшебных средств, потому, что текст как раз удобен возможностью произвольной обработки данных, любым удобным способом, в отличии от крыжиков в гуях. А универсального набора крыжиков на все случаи жизни не существует, для каждой программы свои нужны. Ну это как если бы вместо написания программ можно было бы ограничиться работой мышью. PS: В продолжение статьи из linux gazette. Эту штуку http://ndevilla.free.fr/etrace/ похоже можно допилить для нужного контроллера. И тут очень пригодятся безумные идеи EvgenyCD, мол связать контроллер и ПК очень быстрым интерфейсом для получения отладочной информации (её будет нереально много же). Но если ближе к практике, то максимум что у нас есть -- это, наверное, SPI. Если там разогнать до десятков МГц, то вопрос, чем принимать со стороны ПК? Ожидать МК никак не может. Нужна железяка со своим большим буфером, способная быстро принять данные из SPI и медленно отдать в USB, например. Не представляю, что это может быть.
[ZX]