History log of /freebsd-10.0-release/tools/tools/gdb_regofs/Makefile
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 259065 07-Dec-2013 gjb

- 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

# 256281 10-Oct-2013 gjb

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

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


# 139103 21-Dec-2004 ru

Start the dreaded NOFOO -> NO_FOO conversion.

OK'ed by: core


# 136910 24-Oct-2004 ru

For variables that are only checked with defined(), don't provide
any fake value.


# 127527 28-Mar-2004 marcel

Add a simple tool that prints out a register offset table to map
from the gdb(1) register number to offsets within struct reg and
struct fpreg. The tool is useful only on selected platforms. On
ia64 the registers are all over the place to simplify handling of
them in various situations, but which makes creating or maintaining
such an offset table error prone to do by hand.
Since remote kernel debugging operates on the same register numbers,
it would be a natural choice to use an identical offset table in the
kernel. However, since the kernel does not operate on struct reg nor
struct fpreg in the remote gdb(1) case, such would not make sense.
Whether we want to use this tool to create offsets for use in the
kernel or duplicate the knowledge of which register number maps to
what register is something that will become clear soon.

Note: in order to build cross debuggers, one cannot use target
headers and/or target definitions. That's why offsets need to be
hardcoded in the first place. Unpleasant, but necessary.