Path: utzoo!attcan!uunet!mcvax!sunic!sics.se!uplog!lynx!bd
From: bd@zyx.SE (Bjorn Danielsson)
Newsgroups: comp.sys.hp
Subject: Incremental loading on 9000/800
Message-ID: <1398@lynx.zyx.SE>
Date: 17 Aug 89 18:41:11 GMT
Reply-To: bd@lynx.zyx.SE (Bjorn Danielsson)
Organization: ZYX Sweden AB, Stockholm, Sweden
Lines: 35

I am having problems with the incremental loading feature in "ld" for the
HP9000 series 800. The linker automatically produces entry and export stubs
for procedure calls to and from data space, and this works correctly in most
cases.

Problem 1:

Using "&" to take the address of a function gives you the address of the
function body rather than the address of the entry stub. When calling such
a function pointer from code space, $$dyncall correctly jumps to data space,
but the function then returns with an ordinary BV 0(%rp) instruction, which
causes the process to crash.

I managed to work around this problem by rewriting $$dyncall so that it
always returns via a generic return stub residing in the same space as the
called function. It works, but I am not really comfortable with using a
nonstandard version of $$dyncall.

Problem 2:

When calling from data space to code space, and the return value is of a
floating-point type, the linker-generated export stub clobbers the return
value. So for example, if sin() is present in my main program and some
dynamically loaded code calls it, an incorrect value is returned.

The only workaround for this is to manually pre-link the target code
with -lm, ensuring that all referenced floating-point functions will
be in data space. The biggest trouble with this is that the linker will
complain about multiply defined symbols, because of the libm functions
already present in code space.

The HP-UX version is A.B3.00, "ld" is A.01.04, and the machine is an 825SRX.
Does anyone know if these problems are fixed in newer HP-UX versions?
-- 
Bjorn Danielsson, ZYX Sweden AB, +46 (18) 69 67 63, bd@zyx.SE