Help with Watcom RTL

117 views
Skip to first unread message

Guenter

unread,
Oct 10, 2010, 9:16:43 PM10/10/10
to
Hi all,
I really need some help with the RTL functions on NetWare; but please read
on now even if you think NetWare is not your thingy - what I ask here is
of generic RTL stuff common to all platforms.
From my previous post 'Linking NetWare NLMs without RTL' you might have
seen with which RTL symbols I have my probs:
> Error! E2028: __I8M is an undefined reference
> Error! E2028: __U8D is an undefined reference
> Error! E2028: __U8M is an undefined reference
> Error! E2028: __U8RS is an undefined reference
> Error! E2028: __I8D is an undefined reference
> Error! E2028: __I8RS is an undefined reference
> Error! E2028: __U8LS is an undefined reference
ok, I have located these symbols in the source file .\OW19\bld\cg\intel
\386\c\386rtrtn.c where's a table which lists them ...
now without diving totally deep into this tuff I cant really see how
finally a function would look like made from this table;
f.e. within the RTL of Metrowerks CodeWarrior (another NetWare-aware but
now dead compiler) I have this in a file LongLongx86.c:
extern s64 __stdcall _rt_mul64(s64 left,s64 right);
extern u64 __stdcall _rt_divu64(u64 left,u64 right);
extern s64 __stdcall _rt_divs64(s64 left,s64 right);
extern u64 __stdcall _rt_modu64(u64 left,u64 right);
extern s64 __stdcall _rt_mods64(s64 left,s64 right);
extern s64 __stdcall _rt_shl64(s64 left,s64 count);
extern u64 __stdcall _rt_shru64(u64 left,s64 count);
extern s64 __stdcall _rt_shrs64(s64 left,s64 count);
extern u64 __stdcall _rt_rotl64(u64 left,s64 count);
extern u64 __stdcall _rt_rotr64(u64 left,s64 count);

and the gerat thing is that these symbols are also supported (exported) by
the OS so I usually dont need the RTL unless doing C++.
Now what I really would like to do is this (where I need some helpfrom you
here):
write some stubs which resolve the Watcom symbols to the OS-provided ones,
f.e. something like that:
__int64 __I8M(__int64 left, __int64 right) {
return _rt_mul64(left, right);
}

but for this I woud need to know exactly how the Watcom functions I listed
above would look like (which is hard to determine from the table in
386rtrtn.c) ...

if that is not possible at all plan B would be to create a stripped-down
Watcom RTL which really only has those 64-bit stuff in and nothing else,
something like a m64bit.lib ...

what do you think? Is the one or other way possible?

Thanks in advance for any hints and help someone may be able to provide!

Günter.

Leif Ekblad

unread,
Oct 11, 2010, 1:01:21 AM10/11/10
to
The actual implementation of those are in the clib project (clib/cgsupp/a).
The objects.mif file in clib/cgsupp does not list novel as a target for
these files, which is why they are not part of the runtime-library.

Leif Ekblad


Steven Levine

unread,
Oct 11, 2010, 1:13:12 AM10/11/10
to
On Mon, 11 Oct 2010 01:16:43 UTC, Guenter <jo...@doe.moon> wrote:

Hi,

> > Error! E2028: __I8M is an undefined reference
> > Error! E2028: __U8D is an undefined reference
> > Error! E2028: __U8M is an undefined reference
> > Error! E2028: __U8RS is an undefined reference
> > Error! E2028: __I8D is an undefined reference
> > Error! E2028: __I8RS is an undefined reference
> > Error! E2028: __U8LS is an undefined reference
> ok, I have located these symbols in the source file .\OW19\bld\cg\intel
> \386\c\386rtrtn.c where's a table which lists them ...

Given that the code you are referring to is part of the code
generator, what you are looking ati si probably a list of functions
that the code generator can either inline or import from a .lib file
at link time.

> but for this I woud need to know exactly how the Watcom functions I listed
> above would look like (which is hard to determine from the table in
> 386rtrtn.c) ...

You need to track down the code that ends up in the plib*.lib
libraries. What you are looking for is problem somewhere in the
bld\clib\cgsupp directory tree.

Steve


--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

Guenter

unread,
Oct 11, 2010, 1:29:16 AM10/11/10
to
Hi Leif,
"Leif Ekblad" <le...@rdos.net> wrote in
news:i8u5ms$pol$1...@www.openwatcom.org:

they are - that is not my prob; I want to avoid the runtime at all because it
drops in some threading stuff beside the 64-bit stuff which I dont need nor
want, and which causes an error message at each start of my app (in my case
Apache httpd). Also just to proof it go and search the lib386/netware folder
for one of the those symbols, f.e. __U8D, and you find them present in all
*.lib files there.

Günter.


Steven Levine

unread,
Oct 11, 2010, 12:26:56 PM10/11/10
to
On Mon, 11 Oct 2010 05:01:21 UTC, "Leif Ekblad" <le...@rdos.net> wrote:

Hi,

> The actual implementation of those are in the clib project (clib/cgsupp/a).
> The objects.mif file in clib/cgsupp does not list novel as a target for
> these files, which is why they are not part of the runtime-library.

These objects are are not Novell specific. I'm not that familiar with
the Novell libraries, but they are probably pulled into the library
with the g32 macro.

Steven

Leif Ekblad

unread,
Oct 11, 2010, 1:56:19 PM10/11/10
to
I think it might depend on compiler switches. RDOS is not listed in
objects.mif
either, and there are not any other of these files elsewhere AFAIK. Maybe it
depends
on inlining settings or something.

Leif Ekblad


"Steven Levine" <ste...@nomail.earthlink.net> skrev i meddelandet
news:11p86vVJT4Oe-p...@slamain.slainc.com...

Steven Levine

unread,
Oct 11, 2010, 5:39:53 PM10/11/10
to
On Mon, 11 Oct 2010 17:56:19 UTC, "Leif Ekblad" <le...@rdos.net> wrote:

Hi,

> I think it might depend on compiler switches. RDOS is not listed in
> objects.mif

It does not need to be given how the makefiles are constructed. For
example, rdos is listed on the #pmake line of
bld\clib\cgsupp\library\generic.386\mf_s\makefile

#pmake: build flat stack 32bit generic cgsupp iX86 dynamic os_dos
os_qnx os_os2 os_nt os_nov os_linux os_rdos cpu_386

which says that a generic 32-bit stack based version of the library
will be built for rdos targets to use. This will inject the object
file names into the g32 macro and they will end up in a library.
Whether or not the functions are ever pulled from the library is
something else.

>Maybe it depends on inlining settings or something.

It depends on how you arranged for the cg to handle function inlining.
Perhaps you set up the system to force inlining. In this case, the
linker will never try to
access a library for these functions.

Guenter

unread,
Oct 23, 2010, 5:51:42 AM10/23/10
to
Hi all,
"Steven Levine" <ste...@nomail.earthlink.net> wrote in news:11p86vVJT4Oe-
pn2-VZ3h...@slamain.slainc.com:

> On Mon, 11 Oct 2010 17:56:19 UTC, "Leif Ekblad" <le...@rdos.net> wrote:
>>Maybe it depends on inlining settings or something.
>
> It depends on how you arranged for the cg to handle function inlining.
> Perhaps you set up the system to force inlining. In this case, the
> linker will never try to
> access a library for these functions.

then unfortunately I didnt find yet the *right* compiler switches ...
I have now put together a very small sample which pulls in 5 of those RTL
symbols to demonstrate the problem here, and everyone who has any Watcom
installation from Watcom 11 to recent OpenWatcom 1.9 can re-create this:
http://www.gknw.net/test/watcom/tst64bit.7z

C:\temp\tst64bit>wmake
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcc386 -bt=netware -zq -wx -fpi -5s -ox -zls -I.\ndk\libc\include
tst64bit.c -fo=tst64bit.obj
%create tst64bit.def
wlink name tst64bit.nlm @tst64bit.def
Open Watcom Linker Version 1.9
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.
loading object files
Error! E2028: __FDU87 is an undefined reference


Error! E2028: __I8D is an undefined reference

Error! E2028: __I8M is an undefined reference
Error! E2028: __U8D is an undefined reference
Error! E2028: __U8M is an undefined reference

creating map file
creating a Novell Netware executable
file tst64bit.obj(C:\temp\tst64bit\tst64bit.c): undefined symbol __FDU87
file tst64bit.obj(C:\temp\tst64bit\tst64bit.c): undefined symbol __I8D
file tst64bit.obj(C:\temp\tst64bit\tst64bit.c): undefined symbol __I8M
file tst64bit.obj(C:\temp\tst64bit\tst64bit.c): undefined symbol __U8D
file tst64bit.obj(C:\temp\tst64bit\tst64bit.c): undefined symbol __U8M
Error(E42): Last command making (tst64bit.nlm) returned a bad status
Error(E02): Make execution terminated

if you set the environment var:
set use_wcrtl=1
then the sample links successfully with Watcom RTL (which is what's not
usable for me as outlined in earlier posts):
C:\temp\tst64bit>wmake
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcc386 -bt=netware -zq -wx -fpi -5s -ox -I.\ndk\libc\include
tst64bit.c -fo=tst64bit.obj
%create tst64bit.def
wlink name tst64bit.nlm @tst64bit.def
Open Watcom Linker Version 1.9
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.
loading object files
searching libraries
creating map file
creating a Novell Netware executable

please see the Makefile section which creates the linker def file where I
also have to import CurrentProcess when linking with RTL which is part of
my problem since its a CLIB [1] funcion and seems to cause the trouble I
have when linking with the RTL. If inlining of *only* the 64-bit math
functions would work then this import would be obsolete - so if someone
has an idea for the right compiler switch, and can successfully link
without import of CurrentProcess that would probably the solution ...

thanks, G�nter.

[1] CLIB is the old propietary NetWare architecture, where newer software
like Apache httpd is based on the more posix-like NetWare LIBC
architecture.

Reply all
Reply to author
Forward
0 new messages