The functions now take a bitmask in argument since commit d7416c6f79
("perf_event: Specify counter by bit_mask on start/stop")...
Thanksfully the change also induced a type modification so it was easy
to notice.
(On the other hand I'm building with --disable-perf so why the hell is
that file compiled?!)
Change-Id: Ie16367cc94e81068b70e1b80142a6394de896c4f
Some enums were redefined in lib/include/mc_perf_event.h in commit
1284060 ("support PERF_TYPE_{HARDWARE|HWCACHE} in perf_event_open")
Change-Id: I1a98699955ca7fd6135b2a7dde72ed4df77b1974
This function was added for x86 by commit 140f813d77 ("fix:
differences in behavior of sigaction between Linux and Mckernel")
The x86 and arm files are actually pretty close and could use
factoring...
Change-Id: Ia8820fd2f824d898610b384a3e137c96aadbc911
Probably only needed for recent system, see ihk's 3271b5e6 ("fix
compilation with recent glibc (cpu_set define change)")
The root of the problem really is that we rely on system headers for
mckernel that ought to be independent...
Change-Id: Ieb9a017e5a7697ad767087370ced7b615efc917e
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
Was done in x86_64 for fileobj in commit 249bda4aef ("fileobj: use
MCS locks for per-file page hash")
Change-Id: I61957de336b6657687803e6288afed9360a42032
This is for linking only. visit_pte_range_safe() is required only
for memdump, as far as i can tell. Since memdump is disabled anyway
I think it's ok to leave this function empty for now.
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)
