Hi,
On 07/05/07 10:17, ?? Tao Jie wrote:
> What's the difference?
Debug bits are compiled with DEBUG defined (-DDEBUG on cc cmdline etc).
So any code that is bracketed by a #ifdef DEBUG ... #endif becomes
active. This brings additional levels of debug and checking to
life, eg in the sample code:
#ifdef DEBUG
static void
check_for_cycles(struct fooey *fp)
{
...
}
#endif
int
foo(struct fooey *fp)
{
ASSERT(fp && fp->foo_type == FOO_TYPE1);
...
#ifdef DEBUG
check_for_cycles(fp);
#endif
...
}
The ASSERT code will be compiled if compiled with DEBUG; if not
it will disappear at preprocessing because the definition of
ASSERT changes depending on whether DEBUG is defined or not.
The second bit illustrates one of the reasons that a DEBUG kernel/system
is much slower. Instead of a simple invariant check as in the
assertion this will perform additional work such as verifying the
contents and structure of a linked list. Many debug options
are enabled with DEBUG, such as kmem_flags to perform redzone
violation checking etc - all good for debug and verification,
but at a cost to performance.
> When using the debug ON, what messages can I get?
A few more during boot that aren't interesting. Thereafter, since
there are more checks. potentially new whinges and panics if
inconsistencies are found.
> How can I build a non-debug ON? just use the non-debug on-closed-bins?
If using bldenv the default is non-debug; use the -d flag for debug.
If using nightly then change NIGHTLY_OPTIONS to select debug + non-debug,
debug only, or non-debug only. From the nightly usage message:
/opt/onbld/bin/nightly -?
/opt/onbld/bin/nightly[1035]: getopts: ? bad option(s)
Usage: nightly [-in] [-V VERS ] [ -S E|D|H|O ] <env_file>
Where:
-i Fast incremental options (no clobber, lint, check)
-n Do not do a bringover
-V VERS set the build version string to VERS
-S Build a variant of the source product
E - build exportable source
D - build domestic source (exportable + crypt)
H - build hybrid source (binaries + deleted source)
O - build (only) open source
<env_file> file in Bourne shell syntax that sets and exports
variables that configure the operation of this script and many of
the scripts this one calls. If <env_file> does not exist,
it will be looked for in $OPTHOME/onbld/env.
non-DEBUG is the default build type. Build options can be set in the
NIGHTLY_OPTIONS variable in the <env_file> as follows:
-A check for ABI differences in .so files
-C check for cstyle/hdrchk errors
-D do a build with DEBUG on
-F do _not_ do a non-DEBUG build
-G gate keeper default group of options (-au)
-I integration engineer default group of options (-ampu)
-M do not run pmodes (safe file permission checker)
-N do not run protocmp
-O generate OpenSolaris deliverables
-R default group of options for building a release (-mp)
-U update proto area in the parent
-V VERS set the build version string to VERS
-X copy x86 IHV proto area
-a create cpio archives
-f find unreferenced files
-i do an incremental build (no "make clobber")
-l do "make lint" in $LINTDIRS (default: $SRC y)
-m send mail to $MAILTO at end of build
-n do not do a bringover
-o build using root privileges to set OWNER/GROUP (old style)
-p create packages
-r check ELF runtime attributes in the proto area
-t build and use the tools in $SRC/tools
-u update proto_list_$MACH and friends in the parent workspace;
when used with -f, also build an unrefmaster.out in the parent
-w report on differences between previous and current proto areas
-z compress cpio archives with gzip
-W Do not report warnings (freeware gate ONLY)
-S Build a variant of the source product
E - build exportable source
D - build domestic source (exportable + crypt)
H - build hybrid source (binaries + deleted source)
O - build (only) open source
You'll have to pair them with the apporopriate debug or non-debug closed
bits.
Gavin
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
