Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!sun-barr!apple!motcsd!hpda!hpcuhb!hpcllla!hpclisp!hpclmar!mar
From: mar@hpclmar.HP.COM (Michelle Ruscetta)
Newsgroups: comp.sys.hp
Subject: Re: Incremental loading on 9000/800
Message-ID: <1340067@hpclmar.HP.COM>
Date: 18 Aug 89 21:30:45 GMT
References: <1398@lynx.zyx.SE>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 50

> 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.

   Clever workaround! This is a known problem in HP-UX version A.B3.00 and
   A.B3.01, linker versions A.01.04 - A.01.11, fixed in version A.01.14 
   (which will be available in the HP-UX 7.0 release -- A.B7.00).
   
> 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.
> 

   I was unable to duplicate this problem -- I used a call to sqrt from the
   dynamic function to the main program and it worked just fine (using A.01.04).
   Things to check (these are simple but the only things I could think of that
   may be causing you problems): Is sin() defined properly in the main 
   program, that is, defined as returning a double? Does the dynamic function
   declare sin() properly (extern double sin())? Pramter-relocation works 
   for specifying which registers to use for return values and arguments, but
   will not perfrom conversions, so returning a float where a double is
   expected, etc. will still appear 'broken'.


> Bjorn Danielsson, ZYX Sweden AB, +46 (18) 69 67 63, bd@zyx.SE

-- Michelle Ruscetta