Don't bother setting -fno-omit-frame-pointer if PROF is set; the in-tree
GCC now does the right thing with instrumented function frames regardless
of command line options.
More profiling fixes:
- Define NO_PROFILE_COUNTERS=1 and don't emit a profile counter references
in FUNCTION_PROFILER() -- our __mcount() doesn't actually need/use them.
- In SUBTARGET_OVERRIDE_OPTIONS, set flag_omit_frame_pointer=false
if profile_flag is set because our m68k __mcount() relies on standard
m68k stack frames. XXX This is probably better achieved with
{,SUB}TARGET_FRAME_POINTER_REQUIRED, but the m68k back-end doesn't
use that anywhere, so it's a much more invasive change than this.
__mcount() relies on a standard m68k stack frame and the frame pointer for
two things:
1- return address in __mcount()'s frame is used to get selfpc (i.e. the
function being instrumented).
2- __mcount() uses the saved-%fp in its own frame to get the frame pointer
of the instrumented function, which is then used to get return address
in that frame in order to get frompc.
Ensure __mcount()'s stack frame is always set up correctly by decorating
wiht __attribute__((__optimize__("no-omit-frame-pointer"))).
rump: Copy struct proc::p_pgrp explicitly
Now that it's not in p_startcopy/endcopy, the memcpy isn't enough.
Should fix the thousands of test failures I caused by moving p_pgrp
out of the p_startcopy/endcopy range!
PR kern/60962: fork and spawn read p_pgrp without proc_lock
Fix broken NPF BPFJIT tests.
when compiling BPF byte code, bpf_jit_generate_code called by npf_bpf_compile
expects the size in array count not the raw byte size of the bpf instruction struct.
also, use npf's kernel prepare function to initialize the byte code args.
sparc: Stop exposing default KERNBASE to modules
Otherwise, on kernels with non-standard KERNBASE, modules reference
illegal addresses when using curcpu(), curlwp, and so on.
Unfortunately, this cannot be pulled-up to release branches, as
this changes module ABI.
Ride on 11.99.10 version bump.
struct proc: Move p_pgrp out of p_startcopy/endcopy region.
It cannot be safely copied with the current memcpy logic that logic
uses happens without holding proc_lock, so we have to copy it
separately anyway. Leave a comment emphasizing this aspect of the
locking rules so we don't have this bug again.
Looks like p_mqueue_cnt may need similar treatment.
As a result of this kernel ABI change, welcome to 11.99.10!
PR kern/60962: fork and spawn read p_pgrp without proc_lock