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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
