Discussion:
E2028: specifically __STK
(too old to reply)
James Harris (es)
2013-02-16 10:16:21 UTC
Permalink
I am getting the specific symbol __STK as an undefined reference when trying
to link a C function with some assembly. There is no C main() routine. The
app is to start in the assembly code, not the C code. I get the following
errors about a stack not being set up.

wlink file s6.obj, t6.obj

Error! E2028: __STK is an undefined reference
Error! E2028: _big_code_ is an undefined reference
Warning! W1014: stack segment not found
creating a DOS executable
file t6.obj(S:\PROJ\OS\LOAD\HDD\TEST\t6.c): undefined symbol __STK

Even if I add to the wlink command "opt stack=4096" I get the same errors.
This is all 16-bit code.

Anyone know of a 'standard' fix for this or can shed some insights on how
the labels should be defined so I can set them up myself?

James
Hans-Bernhard Bröker
2013-02-16 12:00:57 UTC
Permalink
Post by James Harris (es)
I am getting the specific symbol __STK as an undefined reference when trying
to link a C function with some assembly. There is no C main() routine. The
app is to start in the assembly code, not the C code.
And that's your problem right there. Those undefined symbols would have
been defined by the C startup code, which you decided not to use. If
you're going to do such a thing, it's your responsibility to do all the
things usually supplied by the C startup.

It would almost certainly be easier to just use the C startup and a C
minimal main() that calls your assembly function instead.
James Harris (es)
2013-02-16 14:56:42 UTC
Permalink
This post might be inappropriate. Click to display it.
Frank Beythien
2013-02-16 17:26:31 UTC
Permalink
Post by James Harris (es)
Post by Hans-Bernhard Bröker
Post by James Harris (es)
I am getting the specific symbol __STK as an undefined reference when trying
to link a C function with some assembly. There is no C main() routine. The
app is to start in the assembly code, not the C code.
And that's your problem right there. Those undefined symbols would have
been defined by the C startup code, which you decided not to use. If
you're going to do such a thing, it's your responsibility to do all the
things usually supplied by the C startup.
If I can find out what the symbols are for I should be able to supply them.
__STK
_big_code_ (or _small_code_ depending on the code model chosen)
If I define these and export them from assembly language I can get a clean
compile and link but not knowing what they are for I don't know *how* to
define them - i.e. what should be at each point. The meaning of them is
internal to the OpenWatcom code unless anyone knows of documentation for
them....
Post by Hans-Bernhard Bröker
It would almost certainly be easier to just use the C startup and a C
minimal main() that calls your assembly function instead.
Unfortunately I cannot do that. The C startup code that OW adds calls the
OS - in this case DOS - before it passes control to main. But the code is to
run on a machine which does not have an OS present. Therefore the startup
code will fail before main() gets control.
With your OW installation you probably installed the samples and src
subdirectories (or you can doing a delta installation). There you find
the C startup code, which can give you some ideas about needed C run
time library initialization. This you'll need depending on your used C
RTL functions.

Or you can have a look at
http://ps-2.kev009.com/michaln/os2/os2mini.html
which shows some techniques (for OS/2 in this case) to make a really
small program.

CU
Frank
Wilton Helm
2013-03-14 23:28:21 UTC
Permalink
There are cases where it is desirable (or even necessary) to not use the
normal startup code, such as if it isn't running under an OS, or at least a
supported one. That pretty much describes all my code. However,
particularly if there is C code involved, some form of startup code is
necessary, because a major task of the startup code is to initialize things
the RTL will need.

As Frank points out, the source is available and can be used as a model or
starting point. It takes some effort (and maybe looking at RTL source in
some cases) to figure out what the alternate startup ought to look like, but
it isn't too hard. It is surprising how many programmers with years of
experience have never given a thought to what has to happen *before* a C (or
C++) program can run.

Beyond that, the RTL has some OS dependencies. Two areas are noteworthy:
1. File related, including printf() and friends and scanf() and friends.
This involved OS specific file system, hardware and things like multibyte
tables.
2. Dynamic memory allocation, mallloc() and friend, which are designed to
get blocks of memory from the OS.
My approach is to include replacement functions as needed in my project so
the linker doesn't pull them out of the RTL. Alternately a modified RTL or
higher priority secondary library could be used. For my embedded work,
dynamic memory is forbidden, so I don't use malloc().

Wilton

Steven Levine
2013-02-17 00:57:02 UTC
Permalink
On Sat, 16 Feb 2013 10:16:21 UTC, "James Harris \(es\)"
<***@gmail.com> wrote:

Hi,
Post by James Harris (es)
I am getting the specific symbol __STK as an undefined reference when trying
to link a C function with some assembly. There is no C main() routine. The
app is to start in the assembly code, not the C code. I get the following
errors about a stack not being set up.
wlink file s6.obj, t6.obj
Error! E2028: __STK is an undefined reference
Error! E2028: _big_code_ is an undefined reference
Is your C function a utility routine that does not depend on the C
runtime? If so, I recommend you adjust your compiler switches so that
the generated code does not depend on the C runtime.

_STK is the stack overflow checker. Turn off stack checking and the
requirement for this function will go away. This might be sufficient
for the to get rid of the reference to _big_data, but I'm not sure.

FWIW, you left out the most important piece of information - the
compiler command line.

Steven
--
---------------------------------------------------------------------
Steven Levine <***@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
James Harris (es)
2013-02-17 19:35:43 UTC
Permalink
Post by Steven Levine
On Sat, 16 Feb 2013 10:16:21 UTC, "James Harris \(es\)"
Hi,
Post by James Harris (es)
I am getting the specific symbol __STK as an undefined reference when trying
to link a C function with some assembly. There is no C main() routine. The
app is to start in the assembly code, not the C code. I get the following
errors about a stack not being set up.
wlink file s6.obj, t6.obj
Error! E2028: __STK is an undefined reference
Error! E2028: _big_code_ is an undefined reference
Is your C function a utility routine that does not depend on the C
runtime? If so, I recommend you adjust your compiler switches so that
the generated code does not depend on the C runtime.
_STK is the stack overflow checker. Turn off stack checking and the
requirement for this function will go away.
Thanks Steven! The compiler shows "-s" to remove stack overflow checks. If I
add it to the compile line the problem with __STK goes away. If anyone else
is looking for this later the stack segment still needs to be defined
elsewhere. I do it in the Nasm assembly code with

section .stack class=stack align=16
resb 4096
Post by Steven Levine
This might be sufficient
for the to get rid of the reference to _big_data, but I'm not sure.
It turns out not but based on your advice I found that adding "-zls" to
"remove automatically inserted symbols" fixed the _big_code_ issue.
Post by Steven Levine
FWIW, you left out the most important piece of information - the
compiler command line.
Easily remedied. I tried various compiler and linker options but basically
the original build lines were

nasm -fobj -O2 s6.nasm
wcc t6.c -ml -wx
wlink sys dos name t6 file s6.obj, t6.obj

The new now-working lines are

nasm -fobj -O2 s6.nasm
wcc t6.c -ml -wx -s -zls
wlink sys dos name t6 file t6.obj, s6.obj

James
Loading...