rwm@atronx.OCUnix.On.Ca (Russell McOrmond) (01/07/91)
Here is a message from a friend that has a question: If possible could
you respond to: David.Jones@p8.f109.n163.z1.fidonet.org
For some reason, BLINK is not correctly generating the offset to the global
data (stored off A4) from the value present in A6. I have tried to make a
very small "test" library. The offset generated by BLINK is always zero,
i.e. the function prologue is
LEA LinkerDB(A6),A4
and the linker seems to be using zero for LinkerDB. The funny thing is
that I linked my test library a few days ago and nothing has changed - the
sources are directly from the SAS source directory. Two questions:
What preconditions are necessary for Blink to correctly generate the value
for LinkerDB? I am including libinit.o as the second module and libent.o
as the first module. I am using the LIBFD keyword as well.
How does Blink determine the value to give LinkerDB? LinkerDB must be
equal to the size of the library base structure, which, in the SAS
libinit.c file, is 50 bytes in length. Is this length hard coded? Or is
it derived from the object code somehow (one likely possibility is that
Blink looks at the first longword in the first data hunk in the second
module which explains why libinit.o MUST be the second module.)
Here are listings of all source files other than those provided by SAS:
makefile:
--------
test.library: libfuncs.o libent.o libinit.o lib.fd
blink LIBFD lib.fd TO libs:test.library FROM libent.o libinit.o
libfuncs.o LIB lib:lc.lib
libfuncs.o: libfuncs.c
lc -ml -v libfuncs.c
libent.o: libent.a
asm -iinclude: -u libent.a
libinit.o: libinit.c
lc -ml -v libinit.c
lib.h: lib.fd
fd2pragma lib.fd lib.h
lib.fd:
------
##base _TestBase
##bias 30
Double(x)(D0)
Square(x)(D0)
PutV(x)(D0)
##end
libfuncs.c:
----------
int globV;
int __saveds __asm Double(register __d0 int x) {
return(x << 1); }
int __saveds __asm Square(register __d0 int x) {
return(x * x); }
void __saveds __asm PutV(register __d0 int v) {
globV = v; }
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109peter@cbmvax.commodore.com (Peter Cherna) (01/09/91)
In article <56669.663204707@atronx.OCUnix.On.Ca> rwm@atronx.OCUnix.On.Ca (Russell McOrmond) writes: > > Here is a message from a friend that has a question: If possible could >you respond to: David.Jones@p8.f109.n163.z1.fidonet.org > >For some reason, BLINK is not correctly generating the offset to the global >data (stored off A4) from the value present in A6. I have tried to make a >very small "test" library. The offset generated by BLINK is always zero, >i.e. the function prologue is > >LEA LinkerDB(A6),A4 > >and the linker seems to be using zero for LinkerDB. The funny thing is >that I linked my test library a few days ago and nothing has changed - the >sources are directly from the SAS source directory. Two questions: You must link in the order libent.o+libinit.o+yourstuff.o LinkerDB is evaluated when libinit.o is linked, and is not valid until AFTER libinit.o is linked. Therefore, you cannot access any global data inside libinit.o or any modules linked prior to it, unless you access them off your library base. In particular, ignore the comment in libinit.c that states: "Do library specific public initialization here" If you have any of that to do, do it as a separate routine called from this point, with the routine itself located in another module. It's a little arcane. > Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm > FidoNet 1:163/109 Net Support: (613) 230-2282 > Amiga-Fidonet Support 1:1/109 Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"