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