bd@zyx.SE (Bjorn Danielsson) (08/18/89)
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
mar@hpclmar.HP.COM (Michelle Ruscetta) (08/19/89)
> 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