Gdb: целевой удаленный компьютер подключается не в том месте?

Я изучаю, как использовать OpenOCD и GDB в соответствии с книгой по Rust Embedded.

Есть момент, когда вы подключаетесь к работающему OpenOCD:

(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()

Что-то сломалось без каких-либо изменений, о которых я знаю, и теперь я вижу что-то вроде этого:

(gdb) target remote :3333
Remote debugging using :3333
0x08000bbe in __c_m_sh_syscall ()

С тех пор он не будет работать должным образом. Что означает строка 0x00000000 in ?? () и как все исправить?


embedded rust gdb openocd
person Alexey Orlov    schedule 15.01.2021    source источник
comment
Используя GDB, вы сбрасываете процессор, что означает, что программный счетчик этого процессора будет сброшен на 0x0. Это совершенно нормально, и вы должны иметь возможность делать обычные вещи, которые gdb, например. break main или аналогичный. -- ?? означает, что gdb не знает, какая функция имеет адрес 0x0 (что правильно, потому что ваша программа начинается где-то с 0x80...).   -  person hellow    schedule 15.01.2021
comment
Но почему я больше не вижу этот нулевой адрес? В новом сеансе я вижу 0x08000bbe in __c_m_sh_syscall (). И никаких изменений я не делал.   -  person Alexey Orlov    schedule 15.01.2021

Ответы (1)


arrow_upward
1
arrow_downward

Когда вы подключаетесь к цели с помощью target remote, GDB запрашивает у цели ее текущее состояние регистра, включая значение $pc. GDB НЕ (на тот момент) каким-либо образом изменяет удаленное состояние.

При первом подключении пульт сообщил о $pc значении 0x0. Если удаленное состояние по какой-либо причине изменилось, скажем, вы запустили что-то на удаленном устройстве, то значение $pc может измениться, скажем, на 0x08000bbe.

Если вы затем отключитесь и снова подключитесь, удаленная цель может по-прежнему иметь значение $pc, равное 0x08000bbe, что и увидит GDB.

Как упоминалось в комментариях, GDB просто пытается сопоставить значение $pc с отладочной информацией в вашей программе. ?? показывает, что GDB не может найти никаких символов по адресу 0x0. В то время как GDB нашел символ __c_m_sh_syscall рядом с адресом 0x08000bbe. Однако на данный момент эта информация не имеет большого значения, вы еще ничего не загрузили в цель, так что вы не на самом деле в функции __c_m_sh_syscall, это просто текущий адрес удаленный.

Когда вы выполняете команду load, GDB загружает исполняемый файл в цель и записывает в файл $pc.

TL;ДР; Если ваш рабочий процесс target remote, а затем load, не беспокойтесь о состоянии цели сразу после target remote, это просто случайное состояние, которое происходит в цели при подключении.

person Andrew    schedule 15.01.2021
comment
Большое спасибо! Значит, жизнь начинается после load. Но конечно. Глупо с моей стороны) - person Alexey Orlov; 15.01.2021