- This topic has 4 replies, 2 voices, and was last updated 8 years, 4 months ago by
.
-
Posts
-
I’m using VisualGDB to develop for a nRF51, and the Memory and Disassembly windows are showing different values at the same memory address. I was taking a look at the Interrupt Vector Table (address 0x00000000 on the Cortex M0) in the Memory window in Visual Studio, and I was seeing a lot of invalid addresses. Taking a look at IVT in the disassembly window shows more what I was expecting.
Here’s what I get in the Memory Window:
0x00000000 00 00 00 00 .... 0x00000004 00 00 00 00 .... 0x00000008 00 00 00 00 .... 0x0000000C 00 00 00 00 .... 0x00000010 00 00 00 00 .... 0x00000014 00 00 00 00 .... 0x00000018 00 00 00 00 .... 0x0000001C 00 00 00 00 .... 0x00000020 00 00 00 00 .... 0x00000024 00 00 00 00 .... 0x00000028 00 00 00 00 .... 0x0000002C 00 00 00 00 .... 0x00000030 00 00 00 00 .... 0x00000034 00 00 00 00 .... 0x00000038 00 00 00 00 .... 0x0000003C 00 00 00 00 .... 0x00000040 00 00 00 00 .... 0x00000044 00 00 00 00 .... 0x00000048 00 00 ae 51 ..®Q 0x0000004C 9c ab 86 03 œ«.. 0x00000050 77 33 a2 76 w3¢v 0x00000054 00 00 00 00 .... 0x00000058 08 00 fe 7f ..þ. 0x0000005C 10 00 fe 7f ..þ. 0x00000060 d2 a8 fe 75 Ò¨þu 0x00000064 24 07 7b 01 $.{. 0x00000068 b9 03 00 00 .... 0x0000006C d1 04 00 00 Ñ... 0x00000070 b9 03 00 00 ....And in the Disassembly Window ( I reformatted it to make the difference clearer)
0x00000000 00 80 00 20 0x00000004 65 03 00 00 0x00000008 B9 03 00 00 0x0000000c B9 03 00 00 0x00000010 00 00 00 00 0x00000014 00 00 00 00 0x00000018 00 00 00 00 0x0000001c 00 00 00 00 0x00000020 00 00 00 00 0x00000024 00 00 00 00 0x00000028 00 00 00 00 0x0000002c B9 03 00 00 0x00000030 00 00 00 00 0x00000034 00 00 00 00 0x00000038 B9 03 00 00 0x0000003c B9 03 00 00 0x00000040 B9 03 00 00 0x00000044 B9 03 00 00 0x00000048 B9 03 00 00 0x0000004c B9 03 00 00 0x00000050 B9 03 00 00 0x00000054 00 00 00 00 0x00000058 B9 03 00 00 0x0000005c B9 03 00 00 0x00000060 B9 03 00 00 0x00000064 B9 03 00 00 0x00000068 B9 03 00 00 0x0000006c D1 04 00 00 0x00000070 B9 03 00 00The Disassembly window looks right. However, the Memory window is clearly wrong for any address below 0x00000080. Everything above it seems fine.
Hi,
This is a known bug of GDB. Please try enabling the “Use X command to read memory” option in the VisualGDB Project Properties (GDB Settings page).
I enabled the “Use X command to read memory”, and now Visual Studio 2015 is crashing whenever I hit a breakpoint or pause running.
Hi,
It’s a known issue that will be addressed in the next version with an improved version of the Memory window that relies on the faster live memory interface. We expect to have a preview build with this feature at the end of the next week. As a temporary workaround, please use the ‘x’ command in the GDB Session window manually.
Hi,
We now have a preview build of VisualGDB with the new advanced memory window feature. The new memory window contains workarounds for J-Link stub crashes, can read memory using the live engine while the program is running, allows highlighting global variables, functions and stack frames and is integrated with the Live Variables and Visual Watch features. You can try the preview build here: VisualGDB-5.2.5.916.msi
- You must be logged in to reply to this topic.