FW: Parameter values wrong on indirect functions using gcc 2.95 on HP PA machines

[Jeffrey A Law]

  In message <LPBBLAFLGBBGCHPDLEIEOELNCEAA.dan@artifex.com>you write:
  > 
  > In our software there seems to be a parameter passing problem between
  > a routine called gs_ht_process_screen_memory() in the source module
  > gsht.c and a routine called spot_dummy() in the source module zht1.c.
  > Note:  *phsp->spot_function is pointing at spot_dummy().
  > 
  > To find the problem, I modified gs_ht_process_screen_memory from:
Presumably you're passing a floating point value as a parameter to
an indirect function call?

Presumably you're using HP's assembler?

The bug is in HP's assembler, not GCC.



  > The spot_dummy procedure in zht1.o expects double-precision arguments in
  > %fr5 and %fr7, computes the double-precision result in %fr12, and converts
  > it to a single-precision return value in %fr4L.  This is as expected.
  > 
  > The call in gx_ht_process_screen_memory expects a single-precision return
  > value in %fr4L, so that is OK.  However, it is not obvious how it passes
  > the arguments.  Rather than calling the procedure directly, it uses a
  > runtime support procedure named $$dyncall, whose operation is unknown.
  > It is not loading %fr5 and %fr7 as we would expect.  For other calls (such
  > as the printf calls where we are printing the values) we do see the floatin
  > g
  > point registers being loaded.
For an indirect call, the caller is responsible for putting the values into
integer registers.

The compiler & assembler are supposed to cooperate and tell the linker where
each argument is located for the caller and callee.  If the locations differ
then the linker generates parameter relocation stubs to move parameters around.

The problem is the HP assembler has no way to describe where parameters are
for static functions.

Build & install gas, then reconfigure/rebuild gcc using the "--with-gnu-as"
option.


jeff