avr-gdb & simulavr: соединение потеряно, когда статическая библиотека построена в режиме отладки с помощью cmake - PullRequest
0 голосов
/ 21 апреля 2019

Я использую avr-gdb и simulavr для отладки кода для микроконтроллера atmega328.Мой файл эльфа foo.elf зависит от статической библиотеки bar.a.Я установил Debug как cmake_build_type в CMakeLists.txt bar.a

Когда я вызываю simulavr для создания симуляции, я получаю:

$ simulavr --device=atmega328 --cpufrequency=16000000UL -g -f src/arduinoGridmpc.elf
Waiting on port 1212 for gdb client to connect...

Что и должно быть.Затем я продолжаю запускать avr-gdb в новой оболочке:

$ avr-gdb -p 1212
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
--- snip ---
(gdb) file src/foo.elf
Reading symbols from src/foo.elf...done.
(gdb) target remote localhost:1212
Remote debugging using localhost:1212
0x00000000 in __vectors ()
(gdb) load
Loading section .text, size 0xcf6a lma 0x0
Remote connection closed

, если я проверяю оболочку simulavr:

Waiting on port 1212 for gdb client to connect...
Connection opened by host 127.0.0.1, port -6010.

FATAL: file cmd/gdbserver.cpp: line 326: try to write in flash after last valid address!

Если я устанавливаю тип cmake_build_type для моей статическойбиблиотека bar.a для Release или RelWithDebInfo и перекомпиляции, все работает гладко, и я получаю следующее от simulavr:

Connection opened by host 127.0.0.1, port -5990.

и от avr-gdb:

(gdb) file src/foo.elf
Reading symbols from src/foo.elf...done.
(gdb) target remote localhost:1212
Remote debugging using localhost:1212 
0x00000000 in __vectors ()
(gdb) load
Loading section .text, size 0x2dac lma 0x0
Loading section .data, size 0x42 lma 0x2dac
Start address 0x0, load size 11758
Transfer rate: 395 KB/sec, 904 bytes/write.
(gdb) cont
Continuing.

Что может привести к совершенно другому результату?Почему происходит сбой симулятора simulavr, когда моя статическая библиотека находится в режиме отладки?Эти вопросы ( 1 , 2 , 3 ) похожи, но не совсем совпадают с моими.Кроме того, они не получили ответа.

Я проверил, и тип сборки foo.elf не имеет значения, поэтому не должно быть проблемы смешивания типов сборки.

Спасибо за любые идеи!

...