Need help with Watcom options

I’m working on the getting the next release of C-Kermit:

http://www.columbia.edu/kermit/ckermit.html

ready for release and am running into major roadblocks in QNX. Briefly:

The previous release, 7.0, worked fine. The new release has some new
features (e.g. a built-in scriptable FTP client) that make the program
considerably larger:

$ ls -l kermit
-rwxrwxr-x 1 fdc users 1768025 Nov 30 13:34 kermit
$ size kermit
text data bss decimal hex
1525104 242163 650781 2418048 24e580 kermit
$

The new version builds successfully and works fine on most platforms –
Linux, FreeBSD, Solaris, SunOS, HP-UX, AIX, IRIS, Tru64, SCO, VMS, etc.
In QNX 4.24 and 4.25 it compiles and links without complaint, but
totally misbehaves at runtime. Many of Kermit’s commands result in:

C-Kermit> type foo.txt
5/home/fdc/kermit/kermit terminated (SIGSEGV) at 0007:00095184.
%1 17074 Memory fault ./kermit
$

This generally occurs at the point at which a function is being called.
It is the very call itself that causes the memory fault, not any code
inside the function.

Since the same code works as expected on other platforms, and the
previous release worked on QNX, the most likely explanation is that the
growth in size has exceeded some assumptions that are made by the
compiler and/or linker, and/or the options that are used in the build.

The QNX makefile target was contributed by somebody long ago and it
“just worked” – I never bothered to try to decipher it:

qnx32:
$(MAKE) xermit “LNKFLAGS = -3r” “CFLAGS = -ms -3r … -Oatx …”
“LIBS= -lsocket -lncurses -ltermcap”

As soon as I took a look, I was shocked to find “-ms” (small – i.e. 64K
– memory model). Well, that would explain it! I changed it to -mf
and, surprisingly, it made no difference. Ditto for -ml.

OK, what else? Another option was “-3r”. Changing this to “-3s” made
no difference either. Nor did adding “-r” or “-sg”. The only other
option I could imagine that might have anything to do with all this was
“-zt” (data threshold), but trying different values had no effect either.

I’m stumped. The compiler is Watcom 10.6. Can anybody offer a clue?

  • Frank

Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:


The QNX makefile target was contributed by somebody long ago and it
“just worked” – I never bothered to try to decipher it:

qnx32:
$(MAKE) xermit “LNKFLAGS = -3r” “CFLAGS = -ms -3r … -Oatx …”
“LIBS= -lsocket -lncurses -ltermcap”

As soon as I took a look, I was shocked to find “-ms” (small – i.e. 64K
– memory model).

No, -ms does mean small, that means one segment for code and one
segment for data – but you are in 32-bit land, so each segment is
4G in size. (-mf means code & data share the same segment).

You should normally compile -ms. Link can be either -ms or -mf.
(A library or function compiled -ms can be linked -mf – but not
the other way around.)

Also, I would generally suggest -3r rather than -3s.

OK, what else? Another option was “-3r”. Changing this to “-3s” made
no difference either. Nor did adding “-r” or “-sg”. The only other
option I could imagine that might have anything to do with all this was
“-zt” (data threshold), but trying different values had no effect either.

I’m stumped. The compiler is Watcom 10.6. Can anybody offer a clue?

No ideas, unfortunately.

-David

Try increasing the stack size with option –N.

The default maybe quite small 4K?, other compilers may have different
default and thus you would not see the same behavior.

Often when developing, I set it to 64k or 100k. You can trim this
later to a more reasonable value. Finding stack problems can be like
chasing ghosts as it depends on the nesting of the function call tree
and possibly data in strings, buffers, etc.

Good Luck

Vince


In article <908pdg$dng$1@newsmaster.cc.columbia.edu>,
fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:

I’m working on the getting the next release of C-Kermit:

http://www.columbia.edu/kermit/ckermit.html

ready for release and am running into major roadblocks in QNX.
Briefly:

The previous release, 7.0, worked fine. The new release has some new
features (e.g. a built-in scriptable FTP client) that make the program
considerably larger:

$ ls -l kermit
-rwxrwxr-x 1 fdc users 1768025 Nov 30 13:34 kermit
$ size kermit
text data bss decimal hex
1525104 242163 650781 2418048 24e580 kermit
$

The new version builds successfully and works fine on most platforms -

Linux, FreeBSD, Solaris, SunOS, HP-UX, AIX, IRIS, Tru64, SCO, VMS,
etc.
In QNX 4.24 and 4.25 it compiles and links without complaint, but
totally misbehaves at runtime. Many of Kermit’s commands result in:

C-Kermit> type foo.txt
5/home/fdc/kermit/kermit terminated (SIGSEGV) at 0007:00095184.
%1 17074 Memory fault ./kermit
$

This generally occurs at the point at which a function is being
called.
It is the very call itself that causes the memory fault, not any code
inside the function.

Since the same code works as expected on other platforms, and the
previous release worked on QNX, the most likely explanation is that
the
growth in size has exceeded some assumptions that are made by the
compiler and/or linker, and/or the options that are used in the build.

The QNX makefile target was contributed by somebody long ago and it
“just worked” – I never bothered to try to decipher it:

qnx32:
$(MAKE) xermit “LNKFLAGS = -3r” “CFLAGS = -ms -3r … -Oatx …”
“LIBS= -lsocket -lncurses -ltermcap”

As soon as I took a look, I was shocked to find “-ms” (small – i.e.
64K
– memory model). Well, that would explain it! I changed it to -mf
and, surprisingly, it made no difference. Ditto for -ml.

OK, what else? Another option was “-3r”. Changing this to “-3s” made
no difference either. Nor did adding “-r” or “-sg”. The only other
option I could imagine that might have anything to do with all this
was
“-zt” (data threshold), but trying different values had no effect
either.

I’m stumped. The compiler is Watcom 10.6. Can anybody offer a clue?

  • Frank

Sent via Deja.com http://www.deja.com/
Before you buy.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:908s1t$5u6$1@nntp.qnx.com

Frank da Cruz <> fdc@watsun.cc.columbia.edu> > wrote:


The QNX makefile target was contributed by somebody long ago and it
“just worked” – I never bothered to try to decipher it:

qnx32:
$(MAKE) xermit “LNKFLAGS = -3r” “CFLAGS = -ms -3r … -Oatx …”
“LIBS= -lsocket -lncurses -ltermcap”

As soon as I took a look, I was shocked to find “-ms” (small – i.e. 64K
– memory model).

No, -ms does mean small, that means one segment for code and one
segment for data – but you are in 32-bit land, so each segment is
4G in size. (-mf means code & data share the same segment).

You should normally compile -ms. Link can be either -ms or -mf.
(A library or function compiled -ms can be linked -mf – but not
the other way around.)

Also, I would generally suggest -3r rather than -3s.

Hum all the other version of kermet Frank mentionned seems to be
compile with GCC. SomeC program rely on argument being passed
on the stack as opposed to variable. For these type of program -3s might be
desirable.

OK, what else? Another option was “-3r”. Changing this to “-3s” made
no difference either. Nor did adding “-r” or “-sg”. The only other
option I could imagine that might have anything to do with all this was
“-zt” (data threshold), but trying different values had no effect
either.

I’m stumped. The compiler is Watcom 10.6. Can anybody offer a clue?

No ideas, unfortunately.

-David

In article <908s86$l07$1@nnrp1.deja.com>, <vboyko@my-deja.com> wrote:
: Try increasing the stack size with option -N.
:
Yes, that turned out to be it. I have a Watcom C manual (from 1993)
and this option isn’t listed in it. Didn’t find it in the online
Helpviewer docs either. OK, now I know, thanks!

  • Frank

Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
: In article <908s86$l07$1@nnrp1.deja.com>, <vboyko@my-deja.com> wrote:
: : Try increasing the stack size with option -N.
: :
: Yes, that turned out to be it. I have a Watcom C manual (from 1993)
: and this option isn’t listed in it. Didn’t find it in the online
: Helpviewer docs either. OK, now I know, thanks!

The -N is an option to cc, not wcc/wpp. It corresponds to the OPTION STACK
directive to wlink. Take a look at the docs for cc.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems