Errors while trying to debug in gdb with openocd

[kubaper]

I closed my previous issue, because i finally made the connection, but i have problems with debugging. In on shell i run

"spike --rbb-port=9824 pk test"

where test is simple program in riscv assembly, and i get "Listening for remote bitbang connection on port 9824." then in another shell i run openocd with configuration for rbb provided in riscv-tests directory (i changed hostname to localhost and port to 9824) and i get

"Open On-Chip Debugger 0.10.0-dev-gc431c0eb-dirty (2017-06-07-10:56) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 10000 kHz Warn : Adapter driver 'remote_bitbang' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' Info : Initializing remote_bitbang driver Info : Connecting to localhost:9824 Info : remote_bitbang driver initialized Info : This adapter doesn't support configurable speed Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors Info : Examined RISC-V core Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors riscv.cpu: target state: halted Ready for Remote Connections"

And i totally dont understand this error, but problems just begin there. After this i get in first shell this:

"dmi_read(0x10) -> 0x0 dmi_read(0x11) -> 0xc82 dmi_write(0x10, 0x0) dmi_write(0x10, 0x1) dmi_read(0x10) -> 0x1 dmi_read(0x16) -> 0x10000002 dmi_read(0x11) -> 0xc82 dmi_read(0x11) -> 0xc82 dmi_read(0x10) -> 0x1 dmi_write(0x10, 0x80000001) Debug_rom_entry called for id 0 = 800 dmi_read(0x11) -> 0x382 dmi_read(0x11) -> 0x382 dmi_write(0x10, 0x1) dmi_read(0x16) -> 0x10000002 dmi_write(0x20, 0x7b241473) dmi_write(0x21, 0x417) dmi_write(0x22, 0xfe842e23) dmi_write(0x23, 0x7b241473) dmi_write(0x24, 0xf) dmi_write(0x25, 0x100073) dmi_write(0x26, 0xffffffff) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002 Successful write to program buffer 4 bytes at 340 Debug_rom_entry called for id 0 = 800 dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x20) -> 0x344 dmi_read(0x16) -> 0x10000002 dmi_write(0x20, 0x7b241473) dmi_write(0x21, 0x417) dmi_write(0x22, 0xfe843e23) dmi_write(0x23, 0x7b241473) dmi_write(0x24, 0xf) dmi_write(0x25, 0x100073) dmi_write(0x26, 0xffffffff) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002 Successful write to program buffer 8 bytes at 340 dmi_read(0x16) -> 0x10001002"

and many times this:

"Debug_rom_entry called for id 0 = 800 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x21) -> 0x0 dmi_read(0x20) -> 0x344 dmi_read(0x12) -> 0x112380 dmi_read(0x12) -> 0x112380 dmi_write(0x20, 0x38803023) dmi_write(0x21, 0xf) dmi_write(0x22, 0x100073) dmi_write(0x23, 0xffffffff) dmi_write(0x4, 0x0) dmi_write(0x5, 0x0) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002"

then in gdb in third shell i run

"(gdb) target remote localhost:3333"

and i get

"Remote debugging using localhost:3333 0x0000000000001000 in ?? ()"

and in openocd shell i get "Info : accepting 'gdb' connection on tcp/3333"

This is the end of everything i can do, because then, when i run "monitor reset halt" as it is written in openocd documentation i get again

"Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors"

Then (or without typing monitor reset halt before), no matter what command i use i get

"Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL"

in openocd shell.

When i run "(gdb) load" i get "Loading section .text, size 0x6c4 lma 0x100b0 Loading section .rodata, size 0x8 lma 0x10778 Load failed" in gdb and errors i showed before in openocd shell

Openocd was built without any problems. I am new to openocd so i completely dont know where my problems are. I would be really grateful if anyone would help me to solve them, or just tell me what am i doing wrong.

[mwachs5]

(EDIT, I didn't realize you had already tried without monitor reset halt):

Most of those errors are just noise. Detailed comments below.

On Wed, Jun 7, 2017 at 06:42 kubaper notifications@github.com wrote:

I closed my previous issue, because i finally made the connection, but i have problems with debugging. In on shell i run

"spike --rbb-port=9824 pk test"

where test is simple program in riscv assembly, and i get "Listening for remote bitbang connection on port 9824." then in another shell i run openocd with configuration for rbb provided in riscv-tests directory (i changed hostname to localhost and port to 9824) and i get

"Open On-Chip Debugger 0.10.0-dev-gc431c0eb-dirty (2017-06-07-10:56) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 10000 kHz Warn : Adapter driver 'remote_bitbang' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' Info : Initializing remote_bitbang driver Info : Connecting to localhost:9824 Info : remote_bitbang driver initialized Info : This adapter doesn't support configurable speed Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors Info : Examined RISC-V core Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors riscv.cpu: target state: halted Ready for Remote Connect

That's all fine. you should remove the -expected-id line from your .cfg file, or change it to be 0xdeadbeef (that's what Spike has apparently, the one in your Config file is targeting a SiFive board).

And i totally dont understand this error, but problems just begin there.

After this i get in first shell this:

Thte below looks fine, seems you have debugging output turned on?

"dmi_read(0x10) -> 0x0 dmi_read(0x11) -> 0xc82 dmi_write(0x10, 0x0) dmi_write(0x10, 0x1) dmi_read(0x10) -> 0x1 dmi_read(0x16) -> 0x10000002 dmi_read(0x11) -> 0xc82 dmi_read(0x11) -> 0xc82 dmi_read(0x10) -> 0x1 dmi_write(0x10, 0x80000001) Debug_rom_entry called for id 0 = 800 dmi_read(0x11) -> 0x382 dmi_read(0x11) -> 0x382 dmi_write(0x10, 0x1) dmi_read(0x16) -> 0x10000002 dmi_write(0x20, 0x7b241473) dmi_write(0x21, 0x417) dmi_write(0x22, 0xfe842e23) dmi_write(0x23, 0x7b241473) dmi_write(0x24, 0xf) dmi_write(0x25, 0x100073) dmi_write(0x26, 0xffffffff) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002 Successful write to program buffer 4 bytes at 340 Debug_rom_entry called for id 0 = 800 dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x20) -> 0x344 dmi_read(0x16) -> 0x10000002 dmi_write(0x20, 0x7b241473) dmi_write(0x21, 0x417) dmi_write(0x22, 0xfe843e23) dmi_write(0x23, 0x7b241473) dmi_write(0x24, 0xf) dmi_write(0x25, 0x100073) dmi_write(0x26, 0xffffffff) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002 Successful write to program buffer 8 bytes at 340 dmi_read(0x16) -> 0x10001002"

and many times this:

"Debug_rom_entry called for id 0 = 800 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x16) -> 0x10000002 dmi_read(0x21) -> 0x0 dmi_read(0x20) -> 0x344 dmi_read(0x12) -> 0x112380 dmi_read(0x12) -> 0x112380 dmi_write(0x20, 0x38803023) dmi_write(0x21, 0xf) dmi_write(0x22, 0x100073) dmi_write(0x23, 0xffffffff) dmi_write(0x4, 0x0) dmi_write(0x5, 0x0) dmi_read(0x16) -> 0x10000002 dmi_write(0x16, 0x10000002) dmi_write(0x17, 0x241000) dmi_read(0x16) -> 0x10001002 dmi_read(0x16) -> 0x10001002"

then in gdb in third shell i run

"(gdb) target remote localhost:3333"

and i get

"Remote debugging using localhost:3333 0x0000000000001000 in ?? ()"

That looks good. 0x1000 is the reset vector. So you have successfully connected.

and in openocd shell i get "Info : accepting 'gdb' connection on tcp/3333"

This is the end of everything i can do, because then, when i run "monitor reset halt" as it is written in openocd documentation i get again

"Info : JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Warn : JTAG tap: riscv.cpu UNEXPECTED: 0xdeadbeef (mfg: 0x777 (), part: 0xeadb, ver: 0xd) Error: JTAG tap: riscv.cpu expected 1 of 1: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors"

That is fine. It's just the same errors you were getting the first time you did "reset halt".

Then (or without typing monitor reset halt before), no matter what command i use i get

"Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL"

What do you mean 'no matter what command I use". What commands did you try? How about printing out the $pc?

in openocd shell.

Openocd was built without any problems. I am new to openocd so i completely dont know where my problems are. I would be really grateful if anyone would help me to solve them, or just tell me what am i doing wrong.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/55, or mute the thread https://github.com/notifications/unsubscribe-auth/ARCAJN-imnkFcx7k8WD7fhDzA9lZQauuks5sBqiagaJpZM4NyuNb .

[timsifive]

FWIW, I'm working on updating the README and am running into some issue as well. I'm digging into it but haven't figured out exactly what is going wrong.

[kubaper]

Thanks for your reply @mwachs5, @timsifive ! after reading this http://openocd.org/doc/html/GDB-and-OpenOCD.html i assumed that i have to type

"(gdb) load"

first and after this i get in gdb: "Loading section .text, size 0x6c4 lma 0x100b0 Loading section .rodata, size 0x8 lma 0x10778 Load failed"

and in openocd shell this: Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL

when i just after connection type "(gdb) break 9" (for example) gdb sets breakpoint but in openocd i have the same error which i wrote above and after continuing i get in gdb: "Continuing. Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x101a6

Command aborted."

in openocd again the same error and: "Error: Failed to read original instruction at 0x101a6 Error: can't add breakpoint: unknown reason"

Jumping anywhere or continuing just after connection makes no errors in openocd but i think it starts infinite loop in gdb from what i see.

stepping right after connection throws in gdb "Cannot find bounds of current function"

I don't know if problem is only with load, and other are due to the fact that load didn't work and its just one problem, or there are plenty of them, or i am doing brainless things, but @timsifive 's problems make me hope that is not, or not only my fault :) readme for this whole connection process would be awesome

[mwachs5]

Well, I am guessing Spike doesn't let you write address 0x101a6. Check your linker script and make sure you are loading your program to actually writable location, probably 0x8000_0000.

[kubaper]

0x101a6 is address in main in my compiled program. I only compiled it with riscv64-unknown-elf-gcc and i have done this before on riscv version with gdb support, and i had exactly the same address and i could debug it normally. I guess more important error is this from openocd:

Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL

[mwachs5]

I think that error message doesn't mean it actually exited, just exited from the function where it was trying to write memory. You can run openocd with -d flag to get more info.

I'm not too familiar with the Spike memory map though, so maybe 0x10000 is writable memory, I don't know.

[timsifive]

When you use pk with spike, the kernel will map in pages below 0x80000000 (I think). I’m not sure how that interacts with load. What I’m trying to get working is invoking spike pk and then running gdb , relying on spike/pk to do the loading.

Tim ​

On Wed, Jun 7, 2017 at 10:23 AM, Megan Wachs notifications@github.com wrote:

I think that error message doesn't mean it actually exited, just exited from the function where it was trying to write memory. You can run openocd with -d flag to get more info.

I'm not too familiar with the Spike memory map though, so maybe 0x10000 is writable memory, I don't know.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/55#issuecomment-306865652, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7aqRZ54EfYmTLQ6IKic9nRU5RK_Vks5sBtyhgaJpZM4NyuNb .

[kubaper]

@timsifive did u have similar problems to mine with this debugging or different ones? i wonder if it is just my case and other pople have it working (or have different problems), or just everyone used this only with the real processor not spike so no one needed this. If my actions somewhere caused my problems i can try to solve them somehow, but if problem is in implementation i have completely no power to figure it out.

@mwachs5 running openocd with -d gives me plenty of code like this right after connection:

Debug: 37136 539034 riscv-013.c:1628 riscv013_get_register(): reading register 0x0000001e on hart 0 Debug: 37137 539034 riscv.c:1006 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 37138 539034 riscv.c:1017 riscv_set_current_hartid(): registers already initialized, skipping Debug: 37139 539034 program.c:20 riscv_program_init(): riscv_program_init: p=0x0x7fffb06f27f0 Debug: 37140 539034 program.c:99 riscv_program_alloc_data(): allocating 8 bytes of data Debug: 37141 539034 program.c:117 riscv_program_alloc_data(): allocated 8 bytes at 0x00000380 Debug: 37142 539034 program.c:477 riscv_program_insert(): instruction_count: 0 (p=0x0x7fffb06f27f0) Debug: 37143 539034 program.c:487 riscv_program_insert(): PROGBUF[0] = DASM(0x39e03023) [0x39e03023] Debug: 37144 539034 program.c:477 riscv_program_insert(): instruction_count: 1 (p=0x0x7fffb06f27f0) Debug: 37145 539034 program.c:487 riscv_program_insert(): PROGBUF[1] = DASM(0x0000000f) [0x0000000f] Debug: 37146 539034 program.c:477 riscv_program_insert(): instruction_count: 2 (p=0x0x7fffb06f27f0) Debug: 37147 539034 program.c:487 riscv_program_insert(): PROGBUF[2] = DASM(0x00100073) [0x00100073] Debug: 37148 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[00] = DASM(0x39e03023) Debug: 37149 539034 riscv-013.c:215 scan(): 40b w 39e03023 @20 -> ? Debug: 37150 539034 riscv-013.c:215 scan(): 40b - 00000000 @20 -> ? Debug: 37151 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[01] = DASM(0x0000000f) Debug: 37152 539034 riscv-013.c:215 scan(): 40b w 0000000f @21 -> ? Debug: 37153 539034 riscv-013.c:215 scan(): 40b - 00000000 @21 -> ? Debug: 37154 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[02] = DASM(0x00100073) Debug: 37155 539034 riscv-013.c:215 scan(): 40b w 00100073 @22 -> ? Debug: 37156 539034 riscv-013.c:215 scan(): 40b - 00000000 @22 -> ? Debug: 37157 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[03] = DASM(0xffffffff) Debug: 37158 539034 riscv-013.c:215 scan(): 40b w ffffffff @23 -> ? Debug: 37159 539034 riscv-013.c:215 scan(): 40b - 00000000 @23 -> ? Debug: 37160 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[04] = DASM(0xffffffff) Debug: 37161 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[05] = DASM(0xffffffff) Debug: 37162 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[06] = DASM(0xffffffff) Debug: 37163 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[07] = DASM(0xffffffff) Debug: 37164 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[08] = DASM(0xffffffff) Debug: 37165 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[09] = DASM(0xffffffff) Debug: 37166 539034 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0a] = DASM(0xffffffff) fb06f27f0: debug_buffer[0a] = DASM(0xffffffff) Debug: 37229 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0b] = DASM(0xffffffff) Debug: 37230 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0c] = DASM(0xffffffff) Debug: 37231 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0d] = DASM(0xffffffff) Debug: 37232 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0e] = DASM(0xffffffff) Debug: 37233 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[0f] = DASM(0xffffffff) Debug: 37234 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[10] = DASM(0x00000000) Debug: 37235 539037 riscv-013.c:215 scan(): 40b w 00000000 @04 -> ? Debug: 37236 539037 riscv-013.c:215 scan(): 40b - 00000000 @04 -> ? Debug: 37237 539037 program.c:76 riscv_program_exec(): Executing program 0x0x7fffb06f27f0: debug_buffer[11] = DASM(0x00000000) Debug: 37238 539037 riscv-013.c:215 scan(): 40b w 00000000 @05 -> ? Debug: 37239 539037 riscv-013.c:215 scan(): 40b - 00000000 @05 -> ? Debug: 37240 539037 riscv-013.c:215 scan(): 40b r 00000000 @16 -> ? Debug: 37241 539038 riscv-013.c:208 scan(): 40b - 00000000 @16 -> + 10000002 @16 Debug: 37242 539038 riscv-013.c:215 scan(): 40b w 10000002 @16 -> ? Debug: 37243 539038 riscv-013.c:215 scan(): 40b - 00000000 @16 -> ? Debug: 37244 539038 riscv-013.c:215 scan(): 40b w 00241000 @17 -> ? Debug: 37245 539038 riscv-013.c:215 scan(): 40b - 00000000 @17 -> ? Debug: 37246 539038 riscv-013.c:215 scan(): 40b r 00000000 @16 -> ? Debug: 37247 539038 riscv-013.c:208 scan(): 40b - 00000000 @16 -> + 10001002 @16 Debug: 37248 539038 riscv-013.c:215 scan(): 40b r 00000000 @16 -> ? Debug: 37249 539039 riscv-013.c:208 scan(): 40b - 00000000 @16 -> + 10001002 @16 Debug: 37250 539039 riscv-013.c:215 scan(): 40b r 00000000 @16 -> ? Debug: 37251 539039 riscv-013.c:208 scan(): 40b - 00000000 @16 -> + 10000002 @16 Debug: 37252 539039 riscv-013.c:215 scan(): 40b r 00000000 @16 -> ? Debug: 37253 539043 riscv-013.c:208 scan(): 40b - 00000000 @16 -> + 10000002 @16 Debug: 37254 539043 riscv-013.c:215 scan(): 40b r 00000000 @04 -> ? Debug: 37255 539047 riscv-013.c:208 scan(): 40b - 00000000 @04 -> + 00000000 @04 Debug: 37256 539047 riscv-013.c:215 scan(): 40b r 00000000 @05 -> ? Debug: 37257 539048 riscv-013.c:208 scan(): 40b - 00000000 @05 -> + 00000000 @05 Debug: 37258 539048 riscv-013.c:590 register_read_direct(): register 0x1f = 0x0 Debug: 37259 539048 riscv.c:676 riscv_openocd_poll(): polling all harts Debug: 37260 539048 riscv.c:1006 riscv_set_current_hartid(): setting hartid to 0, was 0

trying commands like break or continue, or load give me similar code with something like this:

Error: 48296 787751 riscv-013.c:1276 read_memory(): exiting with ERROR_FAIL Debug: 48297 787751 gdb_server.c:1364 gdb_error(): Reporting -4 to GDB as generic error

or this: Error: 60557 980852 riscv-013.c:1495 write_memory(): exiting with ERROR_FAIL Debug: 60558 980852 riscv.c:676 riscv_openocd_poll(): polling all harts

and when i do nothing is keep going with something like this (even without gdb connection): Debug: 63300 1049700 riscv.c:1017 riscv_set_current_hartid(): registers already initialized, skipping Debug: 63301 1049700 riscv.c:660 riscv_poll_hart(): polling hart 0, target->state=2 (TARGET_HALTED=2) Debug: 63302 1049800 riscv.c:676 riscv_openocd_poll(): polling all harts Debug: 63303 1049800 riscv.c:1006 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 63304 1049800 riscv.c:1017 riscv_set_current_hartid(): registers already initialized, skipping Debug: 63305 1049800 riscv.c:660 riscv_poll_hart(): polling hart 0, target->state=2 (TARGET_HALTED=2) Debug: 63306 1049901 riscv.c:676 riscv_openocd_poll(): polling all harts Debug: 63307 1049901 riscv.c:1006 riscv_set_current_hartid(): setting hartid to 0, was 0

But i don't understand this output at all.

[mwachs5]

Tim's answer made sense. Try just debugging the running program instead of actually loading it.

When you see the "ERROR_FAIL" on read/write memory it would be useful to know what addresses you're actually hitting. What if you just connect and do 'b main', 'c' ?

[kubaper]

gdb reacts normally "Breakpoint 1 at0x101a4: file test.s line 7."

openocd prints Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL as always

continue gives "Continuing. Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x101a4

Command aborted." in gdb and once more: Error: unable to execute program: (abstractcs=0x10000302) Error: failed to execute program, abstractcs=0x10000302 Error: exiting with ERROR_FAIL plus: "Error: Failed to read original instruction at 0x101a4 Error: can't add breakpoint: unknown reason" in openocd

It is always the same number 0x10000302 in openocd error regardless of program (i tried simple riscv assembly and hello.c with infinite loop), line of breakpoint or command.

[palmer-dabbelt]

This behavior usually means that the binary is linked somewhere that Spike doesn't have memory. You should check Spike's device tree to ensure there is memory where you linked the program.

[kubaper]

I completely don't know how to do it, i compiled every tool just as was instructed in readmes and i didn't change anything, so i am afraid any "customization" is far beyond my skills and knowledge. Would you be so kind to tell me where to look for this or is it kind of basic information i should have? Anyway, i will later try to find something, but for now thank you all for your attention and patience.

[palmer-dabbelt]

So the problem is that pk enables virtual memory, but OpenOCD expects physical addresses. Thus, what you're doing isn't really by the book. There's some examples of bare-metal programs in the SiFive SDK

https://github.com/sifive/freedom-e-sdk/blob/master/bsp/env/coreplexip-e31-arty/link.lds

that link programs to 0x80000000. The debug tests also do this

https://github.com/riscv/riscv-tests/tree/master/debug

[timsifive]

Is that something that changed? This used to work, at the very least when I first wrote that README.

On Wed, Jun 7, 2017 at 1:17 PM, Palmer Dabbelt notifications@github.com wrote:

So the problem is that pk enables virtual memory, but OpenOCD expects physical addresses. Thus, what you're doing isn't really by the book. There's some examples of bare-metal programs in the SiFive SDK

https://github.com/sifive/freedom-e-sdk/blob/master/bsp/ env/coreplexip-e31-arty/link.lds

that link programs to 0x80000000. The debug tests also do this

https://github.com/riscv/riscv-tests/tree/master/debug

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/55#issuecomment-306912261, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7aTCvnFrCQf_q9Jg60thR_tNk2E6ks5sBwVegaJpZM4NyuNb .

[mwachs5]

One thing that may have changed is I disabled OpenOCD's ability to magically halt before reset. So it is probably farther along in riscv-pk before OpenOCD actually connects. Just a hunch.

EDIT: Maybe I didn't disable it, but I made it not the default. i forget. Looking for the commit I am thinking of.

[mwachs5]

Ah, never mind. This was particular to the debug test suite: https://github.com/riscv/riscv-tests/commit/2b116f9fb820641cb0a3a04e51164f2ef76478d6

[timsifive]

Actually, I think this stopped working when I did the rbb work. When gdb connected directly to spike there was code to perform virtual->physical address translation. That code rightly belongs in OpenOCD, but it's not there yet. So for now it's not possible to debug Linux user code by attaching gdb externally. I'll make that happen some day, but I have higher priority tasks on my plate first. I will update the README with an example that doesn't use pk.

On Thu, Jun 8, 2017 at 2:24 PM, Tim Newsome tim@sifive.com wrote:

Is that something that changed? This used to work, at the very least when I first wrote that README.

On Wed, Jun 7, 2017 at 1:17 PM, Palmer Dabbelt notifications@github.com wrote:

So the problem is that pk enables virtual memory, but OpenOCD expects physical addresses. Thus, what you're doing isn't really by the book. There's some examples of bare-metal programs in the SiFive SDK

https://github.com/sifive/freedom-e-sdk/blob/master/bsp/env/ coreplexip-e31-arty/link.lds

that link programs to 0x80000000. The debug tests also do this

https://github.com/riscv/riscv-tests/tree/master/debug

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/55#issuecomment-306912261, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7aTCvnFrCQf_q9Jg60thR_tNk2E6ks5sBwVegaJpZM4NyuNb .

[palmer-dabbelt]

Before the device tree merge we use to just have one memory parameter: the size of the memory. Thus, on spike, memory started at address 0 and went up to whatever size was requested, modulo whatever holes existed due to devices (like the debug interface).

Post the device tree merge, spike now takes a memory map and leaves explicit holes where devices are expected to go (close to physical 0). Since programs linked around 0 run faster, we link userspace programs near virtual 0. pk does virtual->physical translation, so this is all fine. OpenOCD only handles physical addresses, so it's not legal to load programs at these low addresses.

[timsifive]

Thanks.

On Thu, Jun 8, 2017 at 3:17 PM, Palmer Dabbelt notifications@github.com wrote:

Before the device tree merge we use to just have one memory parameter: the size of the memory. Thus, on spike, memory started at address 0 and went up to whatever size was requested, modulo whatever holes existed due to devices (like the debug interface).

Post the device tree merge, spike now takes a memory map and leaves explicit holes where devices are expected to go (close to physical 0). Since programs linked around 0 run faster, we link userspace programs near virtual 0. pk does virtual->physical translation, so this is all fine. OpenOCD only handles physical addresses, so it's not legal to load programs at these low addresses.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/55#issuecomment-307242657, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7dNBa74MmElFPf8WnOC5Lf1V8hi0ks5sCHLkgaJpZM4NyuNb .

[mwachs5]

Revisiting this... it's not so much that OpenOCD only deals with physical addresses. With the program buffer and triggers, everything is going through the core so the addresses are always virtual (whether virtual == physical inside the core depends on various other arch state). While the symptoms are the same, the issue is that we're trying to load the program before virtual memory is actually set up / without setting MPRV register.

[timsifive]

I've opened #111 to track OpenOCD implementing address translation.

[WilliamWangPeng]

Is that something that changed? This used to work, at the very least when I first wrote that README. … On Wed, Jun 7, 2017 at 1:17 PM, Palmer Dabbelt @.***> wrote: So the problem is that pk enables virtual memory, but OpenOCD expects physical addresses. Thus, what you're doing isn't really by the book. There's some examples of bare-metal programs in the SiFive SDK https://github.com/sifive/freedom-e-sdk/blob/master/bsp/ env/coreplexip-e31-arty/link.lds that link programs to 0x80000000. The debug tests also do this https://github.com/riscv/riscv-tests/tree/master/debug — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7aTCvnFrCQf_q9Jg60thR_tNk2E6ks5sBwVegaJpZM4NyuNb .

https://github.com/riscv/riscv-isa-sim#debugging-with-gdb the README about debugging with GDB works not well, we follow the steps but get the errors and warnings like pwang@york:~/test$ openocd -f spike.cfg Open On-Chip Debugger 0.10.0+dev-00198-g35eed36ff (2019-09-29-23:43) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : Adapter driver 'remote_bitbang' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' Info : Initializing remote_bitbang driver Info : Connecting to localhost:9824 Error: Failed to connect: Connection refused

Segmentation fault (core dumped) pwang@york:~/tools/test/bin$ ./riscv64-unknown-elf-gdb rot13-64 ... ... Type "apropos word" to search for commands related to "word"... Reading symbols from rot13-64... (gdb) target remote localhost:3333 localhost:3333: Connection timed out. (gdb) print wait $1 = 1 (gdb) print wait=0 Cannot access memory at address 0x1001009c

[timsifive]

Did you start spike before running the openocd command? Keep in mind these processes all need to be running simultaneously, so you'll need to run each from a separate shell.