[Lldb-commits] [lldb] [lldb][test] Add expedited-stack-memory backtrace/locals packet test (PR #205897)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

If I was going to make a further comment on the test case style, I'd say there's a lot of complexity in the source that adds no testing value.  Most types will fetch the storage for the variable directly -- from stack memory -- although some like a `char *` variable will fetch the stack memory for the pointer, and then read the c-string at the address.  I think there was one `char *` pointing to a constant string that will be in the file's TEXT segment; you could have a `char  *heapstr = strdup ("second string")` to force a heap one.

Mostly though, what matters here is the size of the stack frame of locals.  We will do our reads in 512 byte increments, and excepting the VLA, I expect all of this to fit in a single read.  As we look at expediting part of the stack frame 0's stack contents in the future, the size of stack frame 0 becomes relevant.  It doesn't really matter if we have a struct of uint32's, or a mix of uint8's, uint16's uint32's and uint64's -- they're all simple ordinals that will require a single memory read from stack to display the variable value, and the only thing that matters would be whether the total storage amount exceeds 512 bytes (or whatever other value we pick for expediting the local stack frame). This function could just as easily be `uint64_t v1 = 0; uint64_t v2 = 1; uint64_t v3 = 2;` etc - there's a lot of complexity in this test case that adds nothing.

And things like the local variable which is a `long *` pointing to a malloc'ed array of `long`'s - the default formatter for `frame variable` will not print that, you'd need to do a `v *variablename` to have it fetch the heap memory.

https://github.com/llvm/llvm-project/pull/205897