efl debug - add section on Asan

pages/contrib/efl-debug.txt

@@ -293,6 +293,70 @@ Nevermind. That's xlib's display struct. It's private and you don't know what's
 
 In general it's a good idea to spend some quality time with GDB and do all this. If you want others to help with the issue, then mail all the output of GDB during one of these "debugging sessions" and then it can be sifted through by developers for nuggets of information. It may not mean a lot to you, but it means a world developers who sling code around all day long. Sometimes the stack is garbage and there is nothing you can do. Often this means you need to resort to Valgrind to catch things before the stack gets messed up. This gets a bit more intense, BUT to catch the really nasty bugs, you need to run under Valgrind, allowing GDB to attach automatically when things go south.
 
+=== Asan ===
+
+This is almost as good as Valgrind below, but drastically faster.
+It's atually usable to build thing with Asan enabled and use them all
+day long. You'll probably find it ueses about 2-3x the CPU and seems to
+use a lot of RAM (virtual size will be huge but overall footprint will
+be fine if you have *Gb or more of RAM). For a decently powerful desktop
+you should be able to use this as a daily driver especially when you are
+hunting bugs. As an would definitely be the preferred deep-debugging
+method and you should build at least EFL and the app9s) (Enlightenment,
+Terminology etc.) with Asan enabled to make it work correctly.
+
+To use Asan you will need to compile libraries and binaries with it
+enabled and have a compiler capable of asan. Given the move to meson,
+this is quite easy now. You will need this in your environmnet before
+you compile and for when you run the application (it needs to be set
+before the process executes):
+
+<code bash>
+export ASAN_OPTIONS=detect_leaks=0:abort_on_error=1::new_delete_type_mismatch=0
+</code>
+
+Ensure this is also in your ~/.xinitrc or ~/.xsession or otherwise
+global environment for your user before anything runs. We only are
+interested in invalid memory accesses (e.g. use after free or
+out-of-bounds accesses etc.). Leaks are a different matter and not
+going to generally be a fatal issue we need Asan to go find.
+
+When youcompile EFL or Enlightenment or Terminology or anything using
+meson add the following option when configuring meson
+(-Db_sanitize=address) and ensure we don't optimize the code so we get
+proper backtraces and symbols and have GDB debugging enabled:
+
+<code bash>
+export CFLAGS="-O0 -g3"
+meson -Db_sanitize=address [other meson options here] . build
+</code>
+
+So just add -Db_sanitize=address as an option in addition to any other
+options you may pass and that build will enable asan for what is being
+built. What this does is instruct the compiler to add extra checking
+code when compiling that does much of what valgrind does at runtime.
+The added instructions generated by the compiler sanitize addresses
+before they are used and adds pointer tracking logic as well. That's
+why this needs to be done at compile time, but since it is done at
+compile time, the resulting binaries are relatively fast (compared to
+using valgrind).
+
+Once you did the above just compile as normal:
+
+<code bash>
+ninja -C build
+ninja -C build install
+</code>
+
+Note that with Asan, debugging any app is just like using gdb but with
+the added extra that Asan will spew out some debug information and
+traces to stderr before aborting (which can be caught in GDB as
+normal). Ylou canuse GD?b to poke around the variables and backtrace
+to see what happened just with the added benefit of the address
+mis-use benig caught immediately and not indirectly "some time later
+after the bug actually happened many hundreds, thousands or millions
+of instructions before".
+
 === Valgrind ===
 
 To debug using Valgrind, enlightenment must be run through Valgrind itself. valgrind cannot be attached like GDB. This can be done by executing Valgrind in a console as shown below.