We do not need two debug.h files.
Take Fujitsu's STATIC_ASSERT over BUILD_BUG_ON because it is more used
Change-Id: If04c17fbb7406ab15fe86267fed8d6da460cec62
Fujitsu: POSTK_DEBUG_ARCH_DEP_9
Since interrupts are disabled on panic, linux cannot reset a
panic'd core when NMI are disabled (for e.g. mcreboot/mcstop)
Just always offline it, so linux can get it back
Change-Id: If8107172375f2924e02bd4c36e24645ec38a8999
these functions are more logical to keep together there as they depend
on each other.
Also add a comment about the __printf attribute, if we have a quiet
period it would be useful to enable and clear the thousands of
warnings...
Change-Id: I47d3891c9cd87da28b2883c29384959f5abd1459
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)
