================
@@ -0,0 +1,29 @@
+#include <malloc/malloc.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+// Produce some names on the trace
+const size_t tag_granule = 16;
+uint8_t *my_malloc(void) { return malloc(2 * tag_granule); }
+uint8_t *allocate(void) { return my_malloc(); }
+
+void my_free(void *ptr) { free(ptr); }
+void deallocate(void *ptr) { my_free(ptr); }
+
+void touch_memory(uint8_t *ptr) { ptr[7] = 1; } // invalid access
+void modify(uint8_t *ptr) { touch_memory(ptr); }
+
+int main() {
+ uint8_t *ptr = allocate();
+ printf("ptr: %p\n", ptr);
----------------
DavidSpickett wrote:
Largely the first one.
> to avoid producing output from test binaries?
Imagine a CI log:
```
PASS: foo
PASS: bar
random output goes here
PASS: abc
more random output goes here is this from the same program who knows we're
using 1024 cores so
PASS: def
the output could end up anywhere
PASS: zzz
```
It gets annoying and sometimes it's hard to find the source of that printf.
print("fixed string") is easy but cout << something << some_func(some other
thing) is gonna take ages to find.
If you ever look at an llvm-test-suite build log you'll see the same thing.
When the compiler crashes, the crash report is split up by a bunch of ninja
processes still doing work.
Different cause there but same type of deal.
General rule is: if it's distracting in any way at all - it shouldn't end up in
the logs. Even if it's harmless, it's minutes people have to spend confirming
that it's harmless.
> What is the reason for preferring to read from a global vs. parsing output?
> Is it more reliable?
If you confirm that it won't spam the log and you do output redirection to
catch it, there's nothing wrong with printing.
Indeed, you may not trust LLDB's ability to read variables in some contexts.
For instance, I'm trying to get expressions working on SME only Linux and I
can't do that by trusting that I can execute an expression. In my case I can
get the job done with memory reads but prints would be another way to do it.
https://github.com/llvm/llvm-project/pull/160952
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
