read.me

来自「开放源码的编译器open watcom 1.6.0版的源代码」· ME 代码 · 共 174 行

WATCOM Object Module Processor
Copyright by WATCOM Systems Inc. 1990.  All rights reserved.
WATCOM is a trademark of WATCOM Systems Inc.
********* CONFIDENTIAL - Preliminary software **************

Usage: WOMP [options]* file [options|file]*

The following options apply to all files which follow them, up to the next
option of the same group.  (i.e., /fm, /fp, and /f- form a group).
A * indicates a default.

/o=spec Output filename/directory specification.  If spec is of the form
        "d:\path\" then output files are written in the named directory.
        If spec is of the form ".ext" then output files are written with the
        extension ".ext".  If spec is a complete file specifier then that
        name is used for the output file.

        A '#' may be used in place of '='.  (For use with DOS SET and .BAT
        files.)

        If this option is not specified, then WOMP will overwrite the original
        object file.

        Examples:

            WOMP /o=.mbj \dev\test.obj
                - creates the file test.mbj in the current directory

            WOMP /o=\codeview\ \dev\test.obj
                - creates the file test.obj in the directory \codeview

            WOMP /o#\codeview\.mbj \dev\test.obj
                - creates the file test.mbj in the directory \codeview

            WOMP /o=foo.bar foo.obj
                - creates the file foo.bar in the current directory

            WOMP foo.obj
                - overwrites the file foo.obj with the converted file

/fm    *Generate Microsoft 16 and 32 bit object files.  If the input object
        file is a 16-bit file, then the output is guaranteed to be a 16-bit
        object file.

/fp     Generate PharLap/EASY OMF 32 bit object files.  If the input object
        file is a 16-bit file, WOMP does its best to convert it to a PharLap
        object file.  This results in USE16 segments, possibly with improper
        access rights.  See PharLap documentation for more information.

/f-     Do not generate an object file (useful with /dx).

/dm    *Generate Microsoft Codeview debugging information.

/dM     Generate Metaware debugging information. Metaware's debugging
        format is a small variation on Microsoft information. Some programs
        that accept output from a Metaware compiler will require a PharLap
        object file (specify /fp).

/dt     Generate Turbo debugging information.

/dx     Generate human readable text to console.

/d-     Do not generate any debugging information.  If the input file
        contained symbolic debugging information it will be lost.  Line
        numbering information will remain.

/pw    *Parse WATCOM debugging information.

/p-     Do not attempt to parse any debugging information. If this option
        is specified, then no attempt is made to interpret the object file's
        contents.  However, WOMP's object file rearrangements still occur.
        i.e., to convert a WCC386 generated PharLap object file into a 
        Microsoft 32-bit object file, one could issue the command:

            WOMP /d- /p- file.obj

        If the /d- is not specified, then artifacts of another debugging
        generator could result.  (i.e., the Microsoft generater would output
        some extra COMENT records)

These toggles are turned on using "/+" and turned off using "/-".

/+q     Be quiet.  WOMP will not print the banner or informational messages.

/+l     Collect default library COMENTs at beginning of file.  If you are using
        Microsoft LINK and wish default library specification (i.e., you are
        not going to use the /nodefault option to LINK) then use this switch.

The following options may appear anywhere:

@spec   WOMP will attempt to access the environment variable "spec"; if that
        does not exist it will open the file named "spec".  The default file
        extension used is ".WMP".  The contents of the file/environment
        variable will be inserted at the point of the @spec command.

!       This can be used for comments in .WMP files.  WOMP ignores all text
        following a ! up to the end of the line.


Regarding input files:

WOMP can understand most .obj files generated by MSDOS compilers and assemblers.
Specifically, WOMP understands:
    Microsoft's variant on Intel 16-bit object files.
    Microsoft style 32-bit object files (Xenix object format).
    PharLap/EASY OMF object files.

There is no need to tell WOMP the style of an input object file since the
formats are distinguishable from one another.


Regarding output files:

To properly do some of the debugging conversions WOMP must rearrange some
records within the object file.  WOMP places all PUBDEFs before the first
LEDATA/LIDATA record.  Additionally, all EXTDEFs and COMDEFs are placed before
the first PUBDEF.  These changes are benign for the most part.  However,
some compilers write COMENT records that are supposed to refer to the next
EXTDEF/COMDEF/PUBDEF.  In this case the COMENT records will be out of place,
and the object file may not be useable.


Using WOMP with WATCOM compilers:

Specify /D2 on the compiler command line (after any /o options) to generate
WATCOM symbolic information.  Then use WOMP on the resulting object file.

The default external naming convention for WATCOM C functions is "name_" 
where "name" is the name of a function.  Some debuggers (i.e., Codeview)
will expect "_name" and will not recognize a command referencing the 
symbol "name".  To work around this problem you must use "name_" whenever 
refering to a function.  (i.e., "go main_")

The default external naming convention for WATCOM FORTRAN functions is
ALL UPPERCASE.  So, you can use "go FMAIN" to begin a FORTRAN program.

WATCOM parameter passing is described in the "User's Guide".  There is no
support for registerized parameters in Microsoft/Metaware debugging
information.  Debuggers working with a WATCOM program might get confused as
to the location of parameters and display random values.  This should not
occur after the function prolog has been executed (i.e., the variables should
be available on the first line of code in any function).  In particular,
Codeview's "Calls" menu will not show valid parameters.


Using Codeview with the output of WOMP:

Unfortunately, Codeview does not understand the entire Microsoft Debugging 
format.  The most noticable area is typedefs.  WOMP makes an attempt to 
resolve any problems Codeview will have with typedefs.  The result is that
types will be displayed in their most basic form while in Codeview (all
typedefs are stripped).

The Microsoft Debugging format does not have a "pointer to void" type in it.
Pointers to void are treated as pointers to char for debugging purposes.

Some FORTRAN types (notably CHARACTER *(*) SAM, and REAL A(1:M)) cannot be
converted to Microsoft format because of code generation differences.  A
warning will be issued in this case.


Using Turbo Debugger with the output of WOMP:

The Turbo debugging format has good support for parameterized functions.
Turbo Debug should have no problem finding parameters when asked for them.

Turbo Debug does not have a FORTRAN mode, so FORTRAN programs will appear
in C mode.  The FORTRAN COMPLEX data type will appear as a C struct with 
two fields named "real" and "imag".

Any other unconvertable type will appear as an array of unsigned characters
(bytes) of the appropriate size.