Comments 13
Интересная получилась встреча, жаль, что наш доклад о СУБД ЛИНТЕР из-за жесткого формата первого дня так и не прозвучал, хоть и был запланирован.
Речицкий Александр тоже есть на Хабре, это я. Большое спасибо за упоминание нашего проекта в Вашем обзоре мероприятия. В целом, обзор получился весьма интересным!
Меры безопасности были такими, поскольку на открытие Иннополиса прилетал Медведев. Поздравил с открытием города и пожелал удачи участникам ВРО. Там в это время еще и Всероссийская Робототехническая Олимпиада проходила. Наша команда серебряные медали заработала (ребятам по 10 лет).
Антон, касательно вашей системы embox, насколько хороша инфраструктура для отладки? Я как понял, в том же GDB можно поглядеть только стектрейс текущего потока? Что касательно info threads, thread NN и т.п.? Просто в реальной практике пришлось, при отладке ThreadX по JTAG, допиливать OpenOCD дабы поддержать ThreadX на ARM926E-JS. Есть ли у вас какой отладочный сервер или патчи для gdb?
Ой, похоже не туда написал. Ответ ниже.
Я посмотрел, что у Вас есть опыт разработки подобных средств, будем благодарны если Вы сделаете поддержку подобного инструмента и для нашего проекта.
Я посмотрел, что у Вас есть опыт разработки подобных средств, будем благодарны если Вы сделаете поддержку подобного инструмента и для нашего проекта.
Ничего страшного.
Интерес чисто праздный, мы в основном аутсорсим или уже готовые проекты или пишем под что-то, где SDK подразумевает определённую ОС. Так получается, что почти повсеместно это ThreadX (Cypress FX3, почти все фотокамеры).
Сейчас, как я понял, у вас используется встренный gdbserver в QEMU, скорее всего, для QEMU его и нужно допиливать. Если внутриплатная отладка, то да, можно доработать OpenOCD, там главное собрать информацию о том, как сохраняются состояния потока на стеке да узнать глобальные структуры которые хранят списки потоков и т.п. информацию. Вы на каких платах с JTAG запускали свою систему?
Интерес чисто праздный, мы в основном аутсорсим или уже готовые проекты или пишем под что-то, где SDK подразумевает определённую ОС. Так получается, что почти повсеместно это ThreadX (Cypress FX3, почти все фотокамеры).
Сейчас, как я понял, у вас используется встренный gdbserver в QEMU, скорее всего, для QEMU его и нужно допиливать. Если внутриплатная отладка, то да, можно доработать OpenOCD, там главное собрать информацию о том, как сохраняются состояния потока на стеке да узнать глобальные структуры которые хранят списки потоков и т.п. информацию. Вы на каких платах с JTAG запускали свою систему?
Интересно, где у нас разрабатывается код для фотокамер:)
Платы, ну довольно много, собственно фактически все платы за исключением больших ARM ов и x86.
Вот некоторый список поддерживаемых платформ, не сочтите за рекламу. JTAG используем от мелких ARM ов STM32 EFM32 и другие до каких нибудь софт процессоров на ПЛИС (microblaze, LEON3).
По поводу доработки gbdserver а для QEMU, думаю Вы правы, но пока в ручном режиме бегаем по списку потоков.
Платы, ну довольно много, собственно фактически все платы за исключением больших ARM ов и x86.
Вот некоторый список поддерживаемых платформ, не сочтите за рекламу. JTAG используем от мелких ARM ов STM32 EFM32 и другие до каких нибудь софт процессоров на ПЛИС (microblaze, LEON3).
По поводу доработки gbdserver а для QEMU, думаю Вы правы, но пока в ручном режиме бегаем по списку потоков.
Два года прошло, а я вам не ответил :)
Интересно, где у нас разрабатывается код для фотокамер:)
Владивосток, Rhonda Software: http://rhondasoftware.com/ и чуточку подробностей: http://rhondasoftware.com/software-solutions/imaging (ну и другие области)
Александр, спасибо за интерес к проекту.
Нет, пока мы не сталкивались с проблемами при отладке, поэтому пользуемся стандартным набором перечисленных Вами средств.
По поводу многопоточности, мы для assert ов добавили стектрейс для всех потоков в системе. У нас есть команда которая позволяет вывести информацию о потоках, это конечно не в отладке но порой помогает. Поэтому я думаю что если потребуется какая то особая поддержка для gdb то ее можно будет добавить.
У нас в свое время была идея затащить gdb сервер, например для отладки по последовательному порту, но поскольку он так и не нашел применение то был убран.
Нет, пока мы не сталкивались с проблемами при отладке, поэтому пользуемся стандартным набором перечисленных Вами средств.
По поводу многопоточности, мы для assert ов добавили стектрейс для всех потоков в системе. У нас есть команда которая позволяет вывести информацию о потоках, это конечно не в отладке но порой помогает. Поэтому я думаю что если потребуется какая то особая поддержка для gdb то ее можно будет добавить.
У нас в свое время была идея затащить gdb сервер, например для отладки по последовательному порту, но поскольку он так и не нашел применение то был убран.
Sign up to leave a comment.
OS Day в Иннополисе