GDB can not access memory address.

[sajjad ahmed]

I am trying to debug my program using debug module but it showing me this.

Breakpoint 1 at 0x1cc: file /home/merl/github_repos/azadi/tests/asm/add.c, line 4. (gdb) c Continuing. Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x1cc Command aborted. (gdb) info mem Using memory regions provided by the target. There are no memory regions defined.

what does it mean how can i define memory regions which gdb can understand??

this is the issue gdb is providing.

(gdb) b main Breakpoint 1 at 0x1cc: file /home/merl/github_repos/azadi/tests/asm/add.c, line 4. (gdb) c Continuing. warning: Invalid remote reply: vCont;c;C;s;S Abstract command ended in error 'busy' (abstractcs=0x8001102) keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2975 ms). Workaround: increase "set remotetimeout" in GDB Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec. Abstract command ended in error 'busy' (abstractcs=0x8001102)

[Tommy Murphy]

Have you tried this?

set mem inaccessible-by-default off

https://sourceware.org/gdb/onlinedocs/gdb/Memory-Region-Attributes.html

It's common to use that especially with embedded targets where the linker script may not provide a complete description of the target memory map.

---

From: sajjad ahmed <sajjad.a...@gmail.com>
Sent: Thursday, March 18, 2021 7:50:56 AM
To: RISC-V HW Dev <hw-...@groups.riscv.org>
Subject: [hw-dev] GDB can not access memory address.

 

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/874996be-3250-4628-9dd3-29152a948f03n%40groups.riscv.org.

[sajjad ahmed]

it is giving same result.

(gdb) set mem inaccessible-by-default off

(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1cc

Command aborted.

[Tommy Murphy]

What is your target RISC-V?

Does it have memory at such a low address?

Is it read/write so that soft breakpoints can be used?

Or is it read-only so that hardware breakpoints must be used (hbreak or thbreak)?

What does an openocd -d verbose log say about the attempted memory/breakpoint access?

---

From: sajjad ahmed <sajjad.a...@gmail.com>
Sent: Thursday, March 18, 2021 10:35:52 AM

To: RISC-V HW Dev <hw-...@groups.riscv.org>

Cc: tommy_...@hotmail.com <tommy_...@hotmail.com>; sajjad ahmed <hw-...@groups.riscv.org>
Subject: Re: [hw-dev] GDB can not access memory address.

 

[sajjad ahmed]

my target is Ibex core. and yes its program memory is read/write.

here is what gdb is showing.

Continuing.
warning: Invalid remote reply: vCont;c;C;s;S
Abstract command ended in error 'busy' (abstractcs=0x8001102)

keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2949 ms). Workaround: increase "set remotetimeout" in GDB

Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Abstract command ended in error 'busy' (abstractcs=0x8001102)

keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2996 ms). Workaround: increase "set remotetimeout" in GDB

Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Abstract command ended in error 'busy' (abstractcs=0x8001102)

keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (3216 ms). Workaround: increase "set remotetimeout" in GDB

Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.

unable to resume hart 0
keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2727 ms). Workaround: increase "set remotetimeout" in GDB
  dmstatus =0x00000382

[Tommy Murphy]

But what is openocd -d showing?

---

From: sajjad ahmed <sajjad.a...@gmail.com>
Sent: Thursday, March 18, 2021 10:48:09 AM

To: RISC-V HW Dev <hw-...@groups.riscv.org>

Cc: tommy_...@hotmail.com <tommy_...@hotmail.com>; sajjad ahmed <hw-...@groups.riscv.org>; sajjad ahmed <hw-...@groups.riscv.org>

[sajjad ahmed]

this is the log message

[Tommy Murphy]

Seems to me that this may be the root of your problem:

Error: 957 3442 riscv-013.c:4237 riscv013_halt_go(): unable to halt hart 0
Error: 958 3442 riscv-013.c:4238 riscv013_halt_go():   dmcontrol=0x80000001
Error: 959 3442 riscv-013.c:4239 riscv013_halt_go():   dmstatus =0x00000c82
Error: 960 3442 riscv-013.c:1728 examine(): Fatal: Hart 0 failed to halt during examine()
Debug: 961 3442 target.c:1820 target_call_event_callbacks(): target event 20 (examine-fail) for core riscv.tap.0
Warn : 962 3442 target.c:771 target_examine(): target riscv.tap.0 examination failed

For some reason that may be to do with the target RISC-V/debug module implementation itself the debugger cannot halt the target.

You probably need to check that the hardware is correctly configured/implemented?

[sajjad ahmed]

I have checked my hardware connections and doesn't find any problem there.

current log file showing me this error

Debug: 9717 90012 riscv-013.c:412 scan():  ->  progbufsize=8 busy cmderr=1 datacount=2
Error: 9718 90012 riscv-013.c:764 wait_for_idle(): Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: 9719 90012 riscv-013.c:768 wait_for_idle(): Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Debug: 9720 90012 riscv-013.c:806 execute_abstract_command(): command 0x221008 failed; abstractcs=0x8001102
Debug: 9721 90017 riscv-013.c:402 scan(): 41b w 00000700 @16 -> + 00000000 @16; 4i
Debug: 9722 90017 riscv-013.c:412 scan():  cmderr=7 ->
Debug: 9723 90022 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 00000700 @16; 4i
Debug: 9724 90022 riscv-013.c:412 scan():  ->  cmderr=7
Debug: 9725 90022 riscv.c:3565 riscv_get_register(): [riscv.tap.0] tselect: ffffffffffffffff
Error: 9726 90022 breakpoints.c:94 breakpoint_add_internal(): can't add breakpoint: unknown reason
Debug: 9727 90022 gdb_server.c:1420 gdb_error(): Reporting -4 to GDB as generic error
Debug: 9728 90022 gdb_server.c:404 gdb_put_packet_inner(): sending packet '$E0E#ba'
Warn : 9729 90022 log.c:417 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (12098 ms). Workaround: increase "set remotetimeout" in GDB
Debug: 9730 90022 riscv.c:2108 riscv_openocd_poll(): polling all harts

[Tommy Murphy]

Do you mean that the "failed to halt" issue is now gone?

If so then what changed?

Are you trying to set a hard breakpoint or a soft breakpoint?

If the former, are you sure that your target implements them (triggers)?

[Tommy Murphy]

Actually this is probably more pertinent:

Error: 9718 90012 riscv-013.c:764 wait_for_idle(): Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: 9719 90012 riscv-013.c:768 wait_for_idle(): Timed out after 2s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Debug: 9720 90012 riscv-013.c:806 execute_abstract_command(): command 0x221008 failed; abstractcs=0x8001102

Seems that the abstract command is timing out and failing so you need to find out why.

I doubt that increasing the timeout will make a difference if it's not succeeding after 2 seconds but you can try this using this command:

https://github.com/riscv/riscv-openocd/blob/riscv/src/target/riscv/riscv.c#L3059

E.g. add -c "riscv set_reset_timeout_sec 10" to your openocd command line increase it to 10 seconds.

If (as I expect) that makes no difference then you need to check on the hardware side as to why this (all?) abstract command(s) fail.

[sajjad ahmed]

yes! that issue is gone now. i am having issue with memory region on executing "info mem"  commands it shows no memory region is defined.

i am inserting soft break points which are supported by the debug module. my question is why it is unable to access memory address. is it related to the linker script?? or is there any specific way to define memory map for gdb??

[Tommy Murphy]

It's a bit confusing because you're changing things without clarifying what you're doing in the context of this specific issue.

E.g. you never previously mentioned what you did to "fix" the failed to halt issue or if the abstract command execution failure is no longer an issue.

What issue are you having when you execute the info mem command?

What error message(s)?

If t here are no error messages and it's simply that it tells you that there are no memory regions defined then that's probably correct.

And in that case you probably still need to use set mem inaccessible-by-default off as I mentioned earlier otherwise some or all memory accesses from gdb will fail.

What is the problem with setting software breakpoints at this stage if any?

Any error message?

Or does the breakpoint get set OK?

And does it fire when you continue execution?

As ever openocd -d logs (or at least the relebant snippets) are useful in the context of unexpected/erroneous debugging behaviour.

[sajjad ahmed]

first of all the issue was with my xbar connections so i fixed that.

now openocd is connecting fine with my target and i am able to reset the target using "monitor reset halt" command.

when i insert break point it is setting fine as .

(gdb) b main
Breakpoint 1 at 0x1cc: file /home/merl/github_repos/azadi/tests/asm/add.c, line 4.

this is fine according to my program.

when i am executing "c" for firing the break point this is the issue i am facing.

(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1cc

Command aborted.

i have increased the time out for command but it didn't work.

i have tried "set mem inaccessible-by-default off" command but the issue is same.

so, i am trying find out the reason why it is unable to access the memory address.

[sajjad ahmed]

this is openocd message for the above issue.

Info : accepting 'gdb' connection on tcp/3333
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2033 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001002). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Warn : Failed to read memory via program buffer.
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (62627 ms). Workaround: increase "set remotetimeout" in GDB
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 20s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: can't add breakpoint: unknown reason

[Tommy Murphy]

OK - so you need to figure out why abstract commands are failing.

[sajjad ahmed]

yes that's the point i need to find.

[Tommy Murphy]

Yes - I would expect that this would involve simulation of the target hardware or something like that?

Not my area of expertise unfortunately so maybe somebody else can pitch in if necessary.