First try with gcc 4.x.x and OpenWatcom wlink.exe as linker
In my Harbour build script:
set EMXOMFLD_TYPE=WLINK
set EMXOMFLD_LINKER=WLINK.EXE
and from OpenWatcom 1.8 copied
\watcom\binp\wlink.exe
\watcom\binp\dll\wlinkd.dll
to some place in PATH
Build process show message:
---------------
emxomfld: warning: 'WLINK' is an invalid value for EMXOMFLD_TYPE.
make[3]: *** [hbpp.exe] Error 1
---------------
make_gnu.log contain:
---------------
gcc -Zomf -Wall -W -O3 -o ..\..\..\..\..\bin\os2\gcc\hbpp.exe hbpp.o
-L../../../../../lib/os2/gcc -Le:\usr\lib\tcpipv4 -lhbcommon -lhbnortl
Open Watcom Linker Version 1.8
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Error! E3033: directive error near '/nofree'
---------------
and this page svn.netlabs.org/repos/libc/trunk/emx/src/emxomf show for
emxomfld.c:
---------------
t = getenv ("EMXOMFLD_TYPE");
if ( t
&& stricmp (t, "WLINK")
&& stricmp (t, "VAC365")
&& stricmp (t, "VAC308")
&& stricmp (t, "LINK386")
)
fprintf (stderr, "emxomfld: warning: '%s' is an invalid value for
EMXOMFLD_TYPE.\n", t);
else if (t)
linker_type = t;
t = getenv ("EMXOMFLD_LINKER");
if (t)
linker_name = t;
---------------
So current emxomfld.exe may not have this code
In this place are code of OS/2 emx/gcc tools
svn.netlabs.org/libc/browser/trunk/emx/src/emxomf
Searching my disk I have:
Directory of E:\BUILDENV20071022\usr\bin
27/06/07 3:56p 65,199 0 a--- emxomfld.exe
11/06/07 8:22a 65,536 0 a--- emxomfld.exe.rel
8/04/06 4:13a 147,450 61 a--- emxomfld.exe.wlink
3 file(s) 278,185 bytes used
Directory of E:\usr\bin
18/03/06 7:19a 61,440 0 a--- emxomfld.exe
E:\usr\bin\emxomfld.exe show message
E:\BUILDENV20071022\usr\bin\emxomfld.exe does not
so the last have WLINK support and must be used
Perhaps emxomfld.exe.wlink could work too
New result of build are:
---------------
make[3]: *** [hbpp.exe] Error 1
---------------
and make_gnu.log show:
---------------
gcc -Zomf -Wall -W -O3 -o ..\..\..\..\..\bin\os2\gcc\hbpp.exe hbpp.o
-L../../../../../lib/os2/gcc -Le:\usr\lib\tcpipv4 -lhbcommon -lhbnortl
Open Watcom Linker Version 1.8
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Error! E3033: file ldE6girq.: line(3): directive error near 'HLL'
---------------
emxomfld.c show:
-----------------
if (!strip_symbols)
fprintf (response_file, "DEBUG HLL\n");
fprintf (response_file, "OPTION QUIET\n");
fprintf (response_file, "OPTION OSNAME='OS/2 EMX'\n");
fprintf (response_file, "OPTION CASEEXACT\n");
-----------------
so error is happening with "DEBUG HLL"
Help for Watcom show for DEBUG directive:
-----------------
Formats: All
The "DEBUG" directive is used to tell the Open Watcom Linker to generate
debugging information in the executable file. This extra information in
the executable file is used by the Open Watcom Debugger. The format of
the "DEBUG" directive (short form "D") is as follows.
DEBUG dbtype [dblist] |
DEBUG [dblist]
dbtype ::= DWARF | WATCOM | CODEVIEW | NOVELL
dblist ::= [db_option{,db_option}]
db_option ::= LINES | TYPES | LOCALS | ALL
DEBUG NOVELL only
db_option ::= ONLYEXPORTS | REFERENCED
The Open Watcom Linker supports four types of debugging information,
"DWARF" (the default), "WATCOM", "CODEVIEW", or "NOVELL".
-----------------
so at first time it seem a mistake of HLL in place of ALL
but this page (content included below):
www.openwatcom.org/index.php/Debugging_Format_Interoperability
show in section "What Would be Good to Have"
IBM HLL debugging information
and lastly, HLL debug format exist
and this message confirm existence of HLL:
--------------------------
Re: Re: [kLIBC] #89: emxomfld: Support wlink (the watcom linker): msg#00052
On Mon, 11 Sep 2006 11:31:02 UTC, "Knut St. Osmundsen" wrote:
> Peter Weilbacher wrote:
> > kLIBC wrote:
> >
> >>#89: emxomfld: Support wlink (the watcom linker)
> >
> >
> > Wow, if I understand correctly from the bug entry you even got the
debug
> > format working fine? So we could use the OW debugger and profiler, too,
> > with GCC-compiled code?
>
> I've got the HLL debug info working fine as far as wlink is concered.
> For the the debugger and profiler, I've got linenumbers and global
> symbols (IIRC) working. So, the OW debugger and profiler isn't yet of
> much use to us.
OK, would have been great, though...
--------------------------
and this other point to right way:
--------------------------
[vbox-dev] building os/2 host
Knut St. Osmundsen schrieb:
[...]
>> Is this a known issue of the os/2 build process? Seems that the
compiler
>> generates a wrong object format (-Zomf switch missing).
>>
>> Any comments?
>
> I haven't updated the prereqs for OS/2 after I did the support driver,
> so it's a little bit inaccurate. You must use the open watcom linker
> (wlink / wl) when building on OS/2. The IBM linker was uncooperative
> (crashes) and I'm switching gcc to use wlink anyway.
>
> You'll find a build of the linker at
> ftp://ftp.netlabs.org/pub/gcc/wl-hll-r1.zip that includes support for
> the OS/2 HLL format. You also need to get GCC 3.3.5 CSD3 / LIBC 0.6.3 in
> order to use this. You'll find that as GCC-3.3.5-csd3.zip in the same
> directory (or in incoming/gcc/ if it hasn't been moved by the time you
> read this). Then SET EMXOMFLD_LINKER=wl.exe and SET EMXOMFLD_TYPE=WLINK
> and you're in business. (Note. if you get funny build errors after
> switching, try 'kmk -C src/VBox/HostDrivers rebuild' or just 'rm -Rf
out'.)
>
> I'll be updating the OS/2 build instructions shortly.
>
> Kind Regards,
> knut
>
Thanks for the hints. Works great now.
Michael
--------------------------
Downloading wl-hll-r1.zip wl.exe show:
--------------------------
[E:\wl-hll-r1]wl
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 1.6beta1 Limited
Availability
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Press CTRL/Z and then RETURN to finish
WLINK>Error! E3013: break key detected
--------------------------
so is an old OpenWatcom linker with support of HLL format
Changing in my Harbour build script:
set EMXOMFLD_TYPE=WLINK
set EMXOMFLD_LINKER=WL.EXE
Harbour build entirely with gcc440/wl.exe linker, including hbrun.exe
and hbmk2.exe.
All Harbour binaries run fine
Conclusions:
- link386.exe limitations with Harbour are left off replacing him with
an old/modified OpenWatcom linker wl.exe
- Entire Harbour for OS/2 can be build with gcc440 and wl.exe linker
Update:
Harbour build entirely with gcc432/gcc433/wl.exe linker, including
hbrun.exe and hbmk2.exe.
All Harbour binaries run fine
Perhaps other way to use current WLINK.exe without HLL support is to
force "strip_symbols"
---------------
if (!strip_symbols)
fprintf (response_file, "DEBUG HLL\n");
fprintf (response_file, "OPTION QUIET\n");
fprintf (response_file, "OPTION OSNAME='OS/2 EMX'\n");
fprintf (response_file, "OPTION CASEEXACT\n");
---------------
I have not tested if it can be done using gcc -Zlinker option
or, as doc say:
---------------
EMXOMFLD_LINKER:
Name of the linker to use and optionally extra parameters.
Spaces in the linker name or path is not supported. Quotes are not
supported either.
---------------
David Macias
Debugging Format Interoperability
From Open Watcom
Jump to: navigation, search
[edit]
What is Currently Supported
Traditionally, Watcom tools have supported three debugging information
formats: Watcom, DWARF, and CodeView. These formats have been supported
since the 10.x product line.
Watcom
The Watcom format was the only format supported in early versions
of Watcom tools. It supports both 16-bit and 32-bit development and it
supports C, C++ and Fortran. It has some capacity limitations, is
considered obsolete, tied to x86 architecture, and its use is not
recommended. Up to and including version 10.6, Watcom was the default
debug debugging information format emitted by the compilers.
CodeView
Open Watcom tools can both generate and read CV4 flavour of the
Microsoft CodeView debugging information format. This format was used by
early releases of Visual C++ and is publicly documented. It supports
both 16-bit and 32-bit debugging and is not tied to the x86
architecture. Currently the Open Watcom linker emits NB05 style debug
data in executable images, which are turned into NB09 format by cvpack.
The DIP (Debugging Information Processor) file used by debugger,
profiler, and Dr. Watcom only reads NB09 data. This format is intended
primarily for interoperability with other tools, many of which can read
or write CodeView debugging information. It has some capacity
limitations (16-bit symbol/type handles).
DWARF
This format is the default since version 11.0. DWARF is by far the
most flexible and extensible (and complex) of these formats. It is not
tied to any operating system or hardware architecture. DWARF is also an
official standard and not a proprietary format like CodeView or Watcom.
Note that Open Watcom tools always package DWARF data in an ELF
container; that is, in ELF executables the DWARF data lives in regular
sections, while other formats (DOS EXE, LX, PE, etc.) will contain a
minimal ELF image appended at the end. As of Open Watcom 1.4, it should
be possible to debug GNU executables with Open Watcom tools and vice
versa. DWARF appears to be the format of choice outside the Microsoft
world.
The above three debugging information formats are full fledged formats
that can contain comprehensive symbol and type information. Currently
there are two other, less capable formats supported:
MAPSYM
This format is generated by IBM/Microsoft MAPSYM tool and .SYM
files in this format are shipped by IBM for OS/2 system components. This
format was also commonly used for 16-bit DOS development. MAPSYM format
has severe capacity limitations (some 16-bit offsets)and only contains
public symbol information. Open Watcom does not provide tools to
generate this format. Support for MAPSYM symbol files was added in OW 1.4.
Exports
This is strictly speaking not a debugging information format at
all. The EXPORTS DIP will look at NE, LX, LE, PE, ELF, and NLM modules
and report information about symbols exported by name to the debugger.
It is useful when calling into DLLs or shared libraries that provide no
debugging information.
[edit]
What Would be Good to Have
Windows .DBG files
These are symbol files delivered by Microsoft for Windows NT system
components. Some contain CodeView information, but it is packaged in a
special format. It is conceivable that the current CodeView DIP could be
extended to handle some of these files. Older Microsoft .DBG files may
also include COFF symbols, which we currently don't support. Source code
and some documentation for reading (undocumented) .DBG and .PDB files
can be found in the book "Undocumented Windows 2000 Secrets". Update:
The book is now available from the author in PDF format here. The
CodeView, .dbg and .pdb file structures are described at the end of
chapter 1. Two more articles on the .pdb format by the same author is
available here. The source code from the companion CD to the book is
also available on the book site, and contains C source code to read and
process .dbg and .pdb files.
IBM HLL debugging information
The HLL format is used by IBM's OS/2 (and presumably Windows)
compilers. It is very similar to old (pre-CV4) CodeView format and uses
the NB04 signature. The format is documented in good detail.
Pre-CV4 CodeView
This format was emitted notably by Microsoft C 6.0 and probably
many other Microsoft tools. Executables using this format have a NB02
signature. It supports both 16-bit and 32-bit debugging, although 32-bit
tools using this format are extremely rare since it was only used for
early (when OS/2 was still under joint development with IBM and
Microsoft) OS/2 2.0 development. IBM OS/2 debuggers understand this
format, and it is very similar to IBM HLL; in fact IBM's NB04 style
debug data may contain both IBM HLL and pre-CV4 CodeView data (this
would happen in mixed 16/32-bit executables). This format appears to be
undocumented, although source code for IBM's SD386 debugger that can
work with this format is available.
Borland
This is the debugging format used by Borland C/C++ and Delphi
tools. It is similar to CodeView in structure, although some details are
different (likely to support Pascal/Delphi debugging). Executables using
this format have a FB09 or FB0A signature. At least the FB09 format is
publicly documented.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
