- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Fix the return value when we found a symbol in .dynstr. This nasty bug was
preventing a lot of symbol lookups in dtruss -s, for example.

- Compute the correct size to reallocate when doubling the size of the
array of loaded objects to avoid a buffer overrun.
- Use reallocf() to avoid leaking memory if the realloc() fails.

PR: kern/175648
Submitted by: yuri@rawbw.com (1)
MFC after: 1 week

Fix libproc test case to work with clang premature optimization
observed with -O2 (used by default).
Avoid function inlining for t1_bkpt_t on which we set a breakpoint.
Otherwise the address of the function is never called thus the
breakpoint never triggers.

Reported by: zont
Reviewed by: rpaulo

Implement DTrace for PowerPC. This includes both 32-bit and 64-bit.

There is one known issue: Some probes will display an error message along the
lines of: "Invalid address (0)"

I tested this with both a simple dtrace probe and dtruss on a few different
binaries on 32-bit. I only compiled 64-bit, did not run it, but I don't expect
problems without the modules loaded. Volunteers are welcome.

MFC after: 1 month

When calling the C++ demangler, make sure to free the returned buffer,
which might have been reallocated.

Pointed out by: stefanf

Add support for demangling C++ symbols. This requires linking libproc with
libc++rt/libsupc++.

Discussed with: theraven

Fix test cases to work with the latest version of the API.

Make sure we visit both symbol sections even if one of them doesn't
exist. This makes it possible to dtrace some C++ programs like devd.

Make libproc compilable for MIPS

fix a serious bug in libproc's proc_attach

proc_attach always frees any struct proc_handle data
that it allocates, but that is supposed to be done
only in error conditions.

PR: bin/158431
Approved by: re (kib)
MFC after: 1 week

Fix a memory leak on the error condition

Reviewed by: rpaulo

Ignore EINTR when calling waitpid.

Several fixes for libproc:
o return the correct status in proc_wstatus()
o proc_read takes a void *
o correctly allocate the objs structure array

Sponsored by: The FreeBSD Foundation

Revert SHLIB_MAJOR to 2.

As discussed with kan@, since DTrace is the only consumer of libproc
right now, there's no need for a major shlib bump.

Bump the shared library major version due to ABI conflicts.

Sponsored by: The FreeBSD Foundation

New version of libproc. Changes are:
* breakpoint setup support
* register query
* symbol to address mapping and vice-versa
* more misc utility functions based on their Solaris counterpart

Also, I've written some test cases.

Sponsored by: The FreeBSD Foundation

Removed redundant -I. from CFLAGS and "yes" from WITHOUT_MAN.

Build lib/ with WARNS=6 by default.

Similar to libexec/, do the same with lib/. Make WARNS=6 the norm and
lower it when needed.

I'm setting WARNS?=0 for secure/. It seems secure/ includes the
Makefile.inc provided by lib/. I'm not going to touch that directory.
Most of the code there is contributed anyway.

Bump the version of all non-symbol-versioned shared libraries in
preparation for 8.0-RELEASE. Add the previous version of those
libraries to ObsoleteFiles.inc and bump __FreeBSD_Version.

Reviewed by: kib
Approved by: re (rwatson)

Merge latest DTrace changes from Perforce.
Update libproc API to reflect new changes.

Approved by: jb

Add the Makefile for the process library which was missed in the previous
commit.

Add a process library with some stubs that the DTrace client needs.
These will be fleshed out as part of the DTrace userland tracing
development.

For now, the kernel tracing part of DTrace requires minimal functionality
for this library.

The API for this library is deliberately different from the libproc in
OpenSolaris due to licensing restrictions.