Description Alexander Gerasimov 2018-05-23 08:39:49 EDT

Created attachment 274148 [details]
issue screenshots and abs dumps

I have a doubtful issue using default CDT Memory View.
Refer to the attached archive to check test dumps and screenshots.

When starting a debug session, the following test:


1 int abc[1024];
2 int main()
3 {
4 int i;
5 for (i=0; i<1024; i++)
6   abc[i] = i;
7 return 321;
8 }

I'm setting breakpoint at line 6 and add a new rendering for abc variable to the standard Memory View, then perform step/continue.

The thing is, if I leave the table focus on the start address for abc var (in my case, it is 0xc0, refer to dumps' .bss section), meaning that the 0xc0 address is at the top of the visible part of table, and perform any kind of step, the updated values starting at 0xc0 represent opcodes from the .text section, which should be placed not at the abc start address, but at the .text section start address (in my case 0x84), refer to step-on-abc-view.png screenshot.

GDB traces in this case shows this request-responce:

493,482 75-data-read-memory-bytes --thread 1 112 248
493,498 75^done,memory=[{begin="0x00000070",offset="0x00000000",end="0x00000168",contents="00009047f\
8ffffff00009047f8ffffff000008740000105000000044000000000000903300001050000027488c0000000000105000001\
050000091310000105000000044c000000041ec1050000090310000117200001032000090310000107200001046010000000\
000087400009033000091310000105000000044ff03000040a010500000105000002c487e000000000010500000105000000\
0444101000007d81050000010500000d747fcffffff0000c0390000c1390000c639000037070000105000001050000037070\
000105000001050000010500000000000000000000000000000000000000000000000000000000000000000"}]

which is the correct answer based on what was requested (read from decimal address 112 with 248 length).

Other case: if I literally scroll the table down for at closest top visible address 0x110 and step now, the correct GDB request is sent and scrolling up to 0xC0 showing the correct numbers (refer to step-on-lower-abc-view.png screenshot).

GDB traces are:

827,849 58-data-read-memory-bytes --thread 1 192 248
827,865 58^done,memory=[{begin="0x000000c0",offset="0x00000000",end="0x000001b8",contents="000000000\
100000002000000030000000400000005000000060000000700000008000000090000000a0000000b0000000c0000000d000\
0000e0000000f000000100000001100000012000000130000001400000015000000160000001700000018000000190000001\
a0000001b0000001c0000001d0000001e0000001f00000020000000210000002200000023000000240000002500000026000\
0002700000028000000290000002a0000002b0000002c0000002d0000002e0000002f0000003000000031000000320000003\
30000003400000035000000360000003700000038000000390000003a0000003b0000003c0000003d000000"}]


As far as I can guess, Memory View table performing table update based on the visible part of the table, adding some cap up and down in case of speed and debugger optimization.

Please, help me understand what kind of logic lies under that and why is rendering works properly only if I scroll the table much lower than I need?