Heavily inspired off linux kernel's dynamic debug:
* add a /sys/kernel/debug/dynamic_debug/control file
(accessible from linux side in /sys/class/mcos/mcos0/sys/kernel/debug/dynamic_debug/control)
* read from file to list debug statements (currently limited to 4k in size)
* write to file with '[file foo ][func bar ][line [x][-[y]]] [+-]p' to change values
Side effects:
* reindented all linker scripts, there is a new __verbose section
* added string function strpbrk
Change-Id: I36d7707274dcc3ecaf200075a31a2f0f76021059
This replaces the chained list used to keep track of all memory ranges
of a process by a standard rbtree (no need of interval tree here
because there is no overlap)
Accesses that were done directly through vm_range_list before were
replaced by lookup_process_memory_range, even full list scan (e.g.
coredump).
The full scans will thus be less efficient because calls to rb_next()
will not be inlined, but these are rarer calls that can probably afford
this compared to code simplicity.
The only reference to the actual backing structure left outside of
process.c is a call to rb_erase in xpmem_free_process_memory_range.
v2: fix lookup_process_memory_range with small start address
v3: make vm_range_insert error out properly
Panic does not lead to easy debug, all error paths
are handled to just return someting on error
v4: fix lookup_process_memory_range (again)
That optimistically going left was a more serious bug than just
last iteration, we could just pass by a match and continue down
the tree if the match was not a leaf.
v5: some users actually needed leftmost match, so restore behavior
without the breakage (hopefully)
