Can't display/i $pc in Scratchpad #8
Comments
|
This error comes from gdb, somehow. It doesn't ask OpenOCD for anything. Specifying the address works: I fear gdb is trying to access the ELF file, and then failing somehow. I'll dig more once the latest riscv gdb builds again. |
|
Is if because of the working area? If I leave off that it will work. Does
gdb think that area is off limits?
…On Mon, Dec 19, 2016 at 11:58 Tim Newsome ***@***.***> wrote:
This error comes from gdb, somehow. It doesn't ask OpenOCD for anything.
Specifying the address works:
(gdb) display/i 0x80000000
6: x/i 0x80000000
=> 0x80000000 <_start>: j 0x8000000c <handle_reset>
I fear gdb is trying to access the ELF file, and then failing somehow.
I'll dig more once the latest riscv gdb builds again.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#8 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ARCAJOfDWds4KzKJlLzPXr5mQ9CjgFFlks5rJuHXgaJpZM4LNjwM>
.
|
|
What's happening is that gdb gets the PC value (0x8000_0000). Then because the PC register has a type of int32, it gets sign extended into an internal address type (which is 64 bits), to 0xffff_ffff_8000_0000. Then gdb tries to find the memory region corresponding to that address, comes up empty, and prints out the error you see. The simple fix is to change the type of all GPRs to be unsigned. I don't know if that's good/bad. You'd usually think of the pc as unsigned, because it contains an address. But what about other GPRs? Some contain addresses, and some just values. If a register contains 0xffffffff it would be nice if gdb prints out its value as -1, which it won't if we tell it the value is unsigned. For comparison, MIPS declares its registers to be signed. I don't know if it has the same problem we have. My inclination is to make GPRs unsigned, and put a comment in there explaining why it is that way. Then when somebody discovers it's an issue, they can read the rationale and make an informed decisions. |
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
Fixes riscv-collab/riscv-openocd#8 Pros of unsigned: addresses with the high bit set work as expected, eg. in "x/i $pc". Pros of signed: values that actually are signed are printed as expected, eg. in "p $t0"
…oo far
Without this, we have some types promoted to `int` when they need to be
`unsigned int`.
Here's some ubsan output hitting this:
Unfortunately, what happens is that things get promoted to `int`, but
need to be `unsigned int`. Here's the ubsan output:
src/helper/types.h:126:65: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x55978a612060 in le_to_h_u32 src/helper/types.h:126
#1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
#2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
#3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
#4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
#5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
#6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
#7 0x55978a528357 in target_poll src/target/target.c:535
#8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
#9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
#10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
#11 0x55978aaed894 in JimInvokeCommand /home/cody/d/openocd-code/jimtcl/jim.c:10364
Change-Id: I24f6abfd26b6980100657397d69c84f2b80a005a
Signed-off-by: Cody P Schafer <[email protected]>
Reviewed-on: http://openocd.zylin.com/4455
Reviewed-by: Tomas Vanek <[email protected]>
Tested-by: jenkins
Reviewed-by: Christopher Head <[email protected]>
I can't currently display instructions which are in Scratchpad memory:
Any thoughts? Is this related to the working area declared at 0x80000000?
If I have a program which is executed from Flash (0x20000000) then it works as expected.
The text was updated successfully, but these errors were encountered: