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