profiling: start

README.adoc

@@ -3809,7 +3809,7 @@ Bibliography:
 
 The ID is just hardcoded on the source:
 
-==== stack smashing detected
+==== stack smashing detected when using glibc
 
 For some reason QEMU / glibc x86_64 picks up the host libc, which breaks things.
 
@@ -3871,7 +3871,7 @@ We pass `-L` by default, so everything just works.
 
 However, in case something goes wrong, you can also try statically linked executables, since this mechanism tends to be a bit more stable, for example:
 
-* QEMU x86_64 guest on x86_64 host was failing with <<stack-smashing-detected>>, but we found a workaround
+* QEMU x86_64 guest on x86_64 host was failing with <<stack-smashing-detected-when-using-glibc>>, but we found a workaround
 * gem5 user only supported static executables in the past, as mentioned at: xref:gem5-syscall-emulation-mode[xrefstyle=full]
 
 Running statically linked executables sometimes makes things break:
@@ -14449,12 +14449,24 @@ Example:: link:userland/c/smash_stack.c[]
 
 Leads to the dreadful "Stack smashing detected" message. Which is infinitely better than a silent break in any case.
 
+We had also seen this error in our repository at: <<stack-smashing-detected-when-using-glibc>>.
+
 ==== Memory leaks
 
 How to debug: https://stackoverflow.com/questions/6261201/how-to-find-memory-leak-in-a-c-code-project/57877190#57877190
 
 Example: link:userland/c/memory_leak.c[]
 
+==== Profiling userland programs
+
+https://stackoverflow.com/questions/375913/how-can-i-profile-c-code-running-on-linux/60265409#60265409
+
+OK, we have to learn this stuff.
+
+Examples:
+
+* link:userland/gcc/profile.c[]: simple profiling example, where certain calls of a certain function can dominate the runtime
+
 === Interpreted languages
 
 Maybe some day someone will use this setup to study the performance of interpreters.