Changed evaluation of variables to functions of gdb

[thorstendb-ARM]

While adding "gdbtarget" to the extension "RTOS Viewer" I was wondering about the relatively complex handling of variable evaluation inside function handleVariableRequestObject() in src/gdb/GDBDebugSessionBase.ts. The issue was, that some of the RTOS variables could not be evaluated because of the array handling. Struct members were encapsulated into [] brackets where they shouldn't.

I refactored parts of that module to use gdb mi commands, see: https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI-Variable-Objects.html
-var-info-expression (for display elements)
-var-info-path-expression (to create and store expressions)

A "major" change is, that array elements are now displayed as "0 = ..." instaed of "[0] = ...".

After this change, the RTOS Viewer displayed FreeRTOS, and my tests with global nested struct / array variables did not show any issue.

[thorstendb-ARM]

@jonahgraham, @asimgunes, @jreineckearm, do you remember why this was done? Have I overlooked something important?

[asimgunes]

Hi @thorstendb-ARM ,

Previously there was a performance issue in the read operations of large array. When user adds a large array (e.g. array length 1K+ items) into the watch variables, there was a significant latency during the step into/over functions which is caused by reading the array again and again in when the thread stops. I afraid introducing the gdb commands into the for loop cause O(n) complexity and can reduce the performance in large arrays. It would be nice to check if this approach is re-introducing the previous issue or not, and I was just wondering if there is any other possible solution to avoid the GDB command executions inside the for loop?

[thorstendb-ARM]

Hi @asimgunes, thank you for the information.
I guess this causes too much traffic when running GDB remotely:

        for (const child of children.children) {
            const varInfoExpression = await this.getInfoExpression(child.name);
            const varInfoPathExpression = await this.getFullPathExpression(child.name);

I have tested (local GDB) a local char array with 2k elements inside an RTOS thread, and it is "same slow" on both implementations (running on Mac M3).

If using GDB calls inside the loop for array elements are too expensive, we could use this fix: #391

[jreineckearm]

@thorstendb-ARM , as discussed offline, this PR goes beyond what we actually need to fix the use of the RTOS views extension. So, I'd suggest to close rather than leaving it here as a stale PR. The pinpointed fix is expected to come with #459 .

Please do not fully discard this branch, though. We may get back to it when we investigate how to rework VarManager and the rest of the expression/variables logic (not scheduled yet).

[thorstendb-ARM]

closed, see #460