[parisc-linux] FWD: The problematic asm code

[parisc-linux] FWD: The problematic asm code

[Randolph Chung]

Torsten, the Debian ghostscript maintainer, has been working on trying
to figure out a weird floating-point related (?) problem with the
ghostscript package on hppa.

Basically, the problem was tracked down to this:
<Bluehorn> (gdb) bt 2
<Bluehorn> #0  gs_distance_transform (dx=0, dy=18, pmat=0xbff01980, pdpt=0xbff01960)
<Bluehorn>     at src/gsmatrix.c:253
<Bluehorn> #1  0x000f53e4 in common_transform (i_ctx_p=0x4067c8,
<Bluehorn>     ptproc=0x3e1562 <__DTOR_END__+22238>,
<Bluehorn>     matproc=0x3e15ba <__DTOR_END__+22326>) at src/zmatrix.c:297
<Bluehorn> tausq: see? dx is zero and dy is 18

<Bluehorn> (gdb) up
<Bluehorn> 297                     code = (*matproc) (opxy[0], opxy[1], pmat, &pt);
<Bluehorn> (gdb) p opxy
<Bluehorn> $15 = {72, 72}

Some disassembly from the code attached. Looks like it's not calling the
function with the right set of registers?

Any ideas?  This might be related to the python2 problem we are seeing
as well...

randolph

----- Forwarded message from Torsten Landschoff <torsten@sarti.debian.org> -----

Date: Thu, 10 Jan 2002 22:21:09 +0000
To: tausq@debian.org
Cc: 122666@bugs.debian.org
Subject: The problematic asm code
From: Torsten Landschoff <torsten@sarti.debian.org>

Hi Randolph, 

This code is generated - I think it is wrong:

                code = (*matproc) (opxy[0], opxy[1], pmat, &pt);
 c30:	34 74 00 50 	ldo 28(r3),r20
 c34:	48 73 00 c0 	ldw 60(sr0,r3),r19
 c38:	6b d3 3f 99 	stw r19,-34(sr0,sp)
 c3c:	34 73 00 40 	ldo 20(r3),r19
 c40:	6b d3 3f 91 	stw r19,-38(sr0,sp)
 c44:	34 13 00 20 	ldi 10,r19
 c48:	2c 73 00 16 	fldd  r19(sr0,r3),fr22
 c4c:	2f c1 12 16 	fstd  fr22,-10(sr0,sp)
 c50:	0f c1 10 99 	ldw  -10(sr0,sp),r25
 c54:	0f c9 10 9a 	ldw  -c(sr0,sp),r26
 c58:	0e 81 10 97 	ldw  -10(sr0,r20),r23
 c5c:	0e 89 10 98 	ldw  -c(sr0,r20),r24
 c60:	48 76 3f a9 	ldw -2c(sr0,r3),r22
 c64:	eb e0 00 00 	b,l c6c <common_transform+0x178>,r31
			c64: R_PARISC_PCREL17F	$$dyncall
 c68:	08 1f 02 42 	copy r31,rp
 c6c:	08 1c 02 53 	copy ret0,r19
 c70:	68 73 00 60 	stw r19,30(sr0,r3)

The source file is src/zmatrix.c from gs-aladdin. Not sure if the 
license would allow pasting it here... Should be the same for gs-6.51, 
but it is harder to build because it includes more stuff so I used
gs-aladdin...

cu
	Torsten

----- End forwarded message -----

-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] FWD: The problematic asm code

[Randolph Chung]

In reference to a message from Randolph Chung, dated Jan 10:
> Torsten, the Debian ghostscript maintainer, has been working on trying
> to figure out a weird floating-point related (?) problem with the
> ghostscript package on hppa.

As a followup... torsten managed to track this down to a simple test
case:


#include <stdio.h>
void	out(const char *str, double x)
{
	printf("%s: %f\n", str, x);
}
int	main(int argc, char **argv)
{
	void	(*f)(const char *, double) = out;
	f("Calling via function pointer", 3.1415926535);
	out("Calling directly", 3.1415926535);
	return 0;
}

This gives:
% ./realind
Calling via function pointer: 0.000000
Calling directly: 3.141593

The RTL and the disassembly shows that in the function pointer case gcc
tries to load the floating point argument into an integer register.

A bug has been filed against gcc upstream about this.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] FWD: The problematic asm code

[John David Anglin]

> #include <stdio.h>
> void	out(const char *str, double x)
> {
> 	printf("%s: %f\n", str, x);
> }
> int	main(int argc, char **argv)
> {
> 	void	(*f)(const char *, double) = out;
> 	f("Calling via function pointer", 3.1415926535);
> 	out("Calling directly", 3.1415926535);
> 	return 0;
> }
> 
> This gives:
> % ./realind
> Calling via function pointer: 0.000000
> Calling directly: 3.141593
> 
> The RTL and the disassembly shows that in the function pointer case gcc
> tries to load the floating point argument into an integer register.

Gcc's behavior is correct.  The ABI specifies that arguments are passed
in general registers in dynamic calls.  This is most likely a linker problem.
The linker has to create the correct stub to copy the argument to a floating
register.  The test runs as expected with HP's som linker.  With the HP
assembler, gcc passes floats in both general and floating registers because
there is no way to specifiy argument locations in static functions.  With
GAS, gcc uses .PARAM to specify argument locations in static functions.

See pa.c around line 7236 for more information on what is being done.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)