VSC variable display sometimes shows wrong values

[joshua-smith-12]

mostly happens after a step, they will show correctly immediately after being set and then become incorrect suddenly.

VSC issues MI commands for var-create to track the variable value. it deletes + recreates all variables each step. i assume it's reading the wrong address for these vars sometimes. need to spend more time debugging MI commands.

[joshua-smith-12]

commands issued are e.g. -var-create - * "delay" the issue is surely GDB-sided since no address is provided, it's reading the wrong address (or value?) for the variable to begin with

[joshua-smith-12]

- * just indicates autogenerated name and current frame. so GDB will lookup delay in the current frame.

[joshua-smith-12]

varobj.varobj_create is the right place to make changes

[joshua-smith-12]

on review, in my favorite test location ov77_021D0D80 the pointer for v0 is off by 4 bytes in memory - GDB also reports only 1 of 2 variables for this function which probably explains the issue, if it counted param1 the v0 pointer would be fine.

GDB likes to pull ov5_021D0D80 for this function if overlay debugging is disabled, ov5_021D0D80 has 1 parameter... so somewhere internally it's looking at the frame for ov5_021D0D80?

wrong, v0 is stored in register

[joshua-smith-12]

most likely a block issue, might require some changes in dwarf code. in mi-cmd-stack.c, line 615, the symbols in the block are iterated but only 2 symbols are shown.

[joshua-smith-12]

in blockframe.c - get_frame_block, calls block_for_pc_sect, calls blockvector_for_pc_sect

calls find_pc_sect_compunit_symtab - this returns the correct cust (i.e. the ov77 file)

but at the top of this chain in mi-cmd-stack.c - list_args_or_locals, struct symbol *sym : block_iterator_range (block) - this shows symbols based on ov5 layout (i believe)

places to look next:

• blockvector_for_pc_sect - b = find_block_in_blockvector (bl, pc); - is it finding the block in ov77 or the first matching block?; run block_iterator_range (block) in all blocks in the bv and inspect symbols to see if an alternative match exists
• blockvector_for_pc_sect - bl = cust->blockvector (); - what is cust->blockvector, how is this populated? (It's totally possible that DWARF loader just finds a block with matching PC and ignores section or something like that)

Looking into cust->blockvector may mean DWARF stuff, so will also want to verify the DWARF debug info is correct before going down that path

[joshua-smith-12]

block: 35460640 - 35460828
    symbol: param0OV77
    symbol: v0OV77

param1 missing, not present in other blocks. need to inspect where cust->blockvector comes from

[joshua-smith-12]

finally bothered to check debuginfo and looks like probably param1 is optimized out, maybe this is a non-issue

confirmed, if I force a reference to param1 it appears in the DWARF. i will test a run with -O0 (which probably should have done from the beginning)

pokeplat dies on -O0 so will need to be more creative with this.

[joshua-smith-12]

my final review on this is that it's probably not solvable in this fork. DWARF debuginfo shows the parameters with issues (e.g. v0 in ov77_021D0D80) are stored in registers, which means if the registers are reused due to optimization the values are unreliable

ref https://gcc.gnu.org/onlinedocs/gnat_ugn/Debugging-Optimized-Code.html... this pretty much explains both this issue and #7

a real resolution would be to somehow compile in such a way that all locals use stack instead of registers, but unsure if mwccarm can do this! even O0 still uses registers for vars.

[joshua-smith-12]

see another issue with this in unk_02017728.c->SetAutorepeat - both rate and delay are mapped to r0 in the debuginfo

this might be a bug in whatever is generating debuginfo? this should not be happening

[joshua-smith-12]

compiling at -O0,p would resolve the 2 issues which remain, but not possible currently in pokeplatinum