(dbx) whatis -t -r class table

class table : public load_bearing_block {

public:

  /* from base class table::load_bearing_block::block */

  block::block();

  block::block(char *name, int w, int h, const class point &pos, class load_bearing_block *blk);

    virtual char *block::type();

    char *block::name();

    int block::is_movable();

//  deleted several members from example protected:

    char *nm;

    int movable;

    int width;

    int height;

    class point  position;

    class load_bearing_block *supported_by;

    Panel_item panel_item;

    /* from base class table::load_bearing_block */

public:

    load_bearing_block::load_bearing_block();

    load_bearing_block::load_bearing_block(char *name, int w, int h,const class point &pos, class load_bearing_block *blk);

    virtual int load_bearing_block::is_load_bearing();

    virtual class list *load_bearing_block::supported_blocks();

    void load_bearing_block::add_supported_block(class block &b);

    void load_bearing_block::remove_supported_block(class block &b);

    virtual void load_bearing_block::print_supported_blocks();

    virtual void load_bearing_block::clear_top();

    virtual void load_bearing_block::put_on(class block &object);

    class point load_bearing_block::get_space(class block &object);

    class point load_bearing_block::find_space(class block &object);

    class point load_bearing_block::make_space(class block &object);

protected:

    class list *support_for;

    /* from class table */

public:

    table::table(char *name, int w, int h, const class point &pos);

    virtual char *table::type();

    virtual void table::draw(unsigned long pw);

};

---

Using the Auto-Read Facility

In general, compile the entire program you want to debug using the -g option. Depending on how the program was compiled, the debugging information generated for each program and shared library module is stored in either the object code file (.o file) for each program and shared library module, or the program executable file.

When you compile with the -g -c compiler option, debugging information for each module remains stored in its .o file. dbx then reads in debugging information for each module automatically, as it is needed, during a session. This read-on-demand facility is called Auto-Read. Auto-Read is the default for dbx.

Auto-Read saves considerable time when you are loading a large program into dbx. Auto-Read depends on the continued presence of the program .o files in a location known to dbx.

By default, dbx looks for files in the directory where they were when the program was compiled and the .o files in the location from which they were linked, using the absolute path recorded at compile time. If the files are not there, use the pathmap command to set the search path.

If no object file is produced, debugging information is stored in the executable. That is, for a compilation that does not produce .o files, the compiler stores all the debugging information in the executable. The debugging information is read the same way as for applications compiled with the -xs option. See "Debugging Without the Presence of .o Files" next.

Debugging Without the Presence of .o Files

Programs compiled with -g -c store debugging information for each module in the module's .o file. Auto-Read requires the continued presence of the program and shared library .o files.

When it is not feasible to keep program .o files or shared library .o files for modules that you want to debug, compile the program using the compiler -xs option (in addition to -g). You can have some modules compiled with -xs and some without. The -xs option instructs the compiler to have the linker place all the debugging information in the program executable; therefore the .o files do not have to be present to debug those modules.

In dbx 4.0, the debugging information for modules compiled with the -xs option is loaded during dbx startup. For a large program compiled with -xs, this might cause dbx to start slowly.

In dbx 5.0, dbx 6.0, and dbx 7.0, the loading of debugging information for modules compiled with -xs is also delayed in the same way as the debugging information stored in .o files.:

Listing Debugging Information for Modules

The module command and its options help you to keep track of program modules during the course of a debugging session. Use the module command to read in debugging information for one or all modules. Normally, dbx automatically and "lazily" reads in debugging information for modules as needed.

To read in debugging information for a module name, type:

(dbx) module [-f] [-q] name

To read in debugging information for all modules, type:

(dbx) module [-f] [-q] -a

where:

-a	Specifies all modules.
-f	Forces reading of debugging information, even if the file is newer than the executable.
-q	Specifies quiet mode.
-v	Specifies verbose mode, which prints language, file names, and so on. This is the default.

To print the name of the current module, type:

(dbx) module

Listing Modules

The modules command helps you keep track of modules by listing module names.

To list the names of modules containing debugging information that have already been read into dbx, type:

(dbx) modules [-v] -read

To list names of all program modules (whether or not they contain debugging information), type:

(dbx) modules [-v]

To list all program modules that contain debugging information, type:

(dbx) modules [-v] -debug

where:

-v	Specifies verbose mode, which prints language, file names, and so on.

 

---

^{1 (FootNote) Loadobject is short for "loadable object" as defined by the SVR4 ABI. Executables (a.out) and shared libraries (*.so) are loadobjects.}

Debugging a Program With dbx

816-2453-10

Copyright © 2002, Sun Microsystems, Inc. All rights reserved.