Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Sat, 23 Sep 2000, John David Anglin wrote:

> Look's like it fixes the problem, although I can't do a complete test now.

Thanks.  I'll commit the change, which goes back to the old SOM handling
for external and weak syms, on the strength of your say-so.  Incidentally,
dhd's original patch was surrounded with #ifdef OBJ_ELF, but I changed
it...

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> Thanks.  I'll commit the change, which goes back to the old SOM handling
> for external and weak syms, on the strength of your say-so.  Incidentally,
> dhd's original patch was surrounded with #ifdef OBJ_ELF, but I changed
> it...

Regarding the #ifdef OBJ_ELF, if it was in as per dhd's original patch,
would this work for --enable-targets=all?

Another question.  The HP linker has a -O option which eliminates
unnecessary addil's (and also dead procedures).  Could this upset
the relative branches built by the assembler if one of the eliminated
addil's was between the branch and target?

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Sat, 23 Sep 2000, John David Anglin wrote:

> Regarding the #ifdef OBJ_ELF, if it was in as per dhd's original patch,
> would this work for --enable-targets=all?

Yes, because the assembler is built only for the primary target.

> Another question.  The HP linker has a -O option which eliminates
> unnecessary addil's (and also dead procedures).  Could this upset
> the relative branches built by the assembler if one of the eliminated
> addil's was between the branch and target?

You probably know more about the HP linker than I do.  I imagine that
removing an addil between a branch and its target is a fairly common
occurrence, so the HP linker should adjust the branch offset.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Jeffrey A Law]

  In message < Pine.LNX.4.21.0009241113120.26851-100000@front.linuxcare.com.au >y
ou write:
 > You probably know more about the HP linker than I do.  I imagine that
  > removing an addil between a branch and its target is a fairly common
  > occurrence, so the HP linker should adjust the branch offset.
Yup -- it has to go back and fix all the pc-relative branches.  It also has
to change the instruction which used the result of the addil to reference
%r27 instead of %r1.

jeff

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

>  > You probably know more about the HP linker than I do.  I imagine that
>   > removing an addil between a branch and its target is a fairly common
>   > occurrence, so the HP linker should adjust the branch offset.
> Yup -- it has to go back and fix all the pc-relative branches.  It also has
> to change the instruction which used the result of the addil to reference
> %r27 instead of %r1.

I raised this point because I thought it might be a mistake for the assembler
not to make all branches with R_PCREL_CALL.  At the present time, short
branches appear to be built directly by the assembler and don't have any
relocation data.  To find these, the linker would have to scan the actual
code around an addil that was being removed.

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Jeffrey A Law]

  In message < 200009241651.MAA16321@hiauly1.hia.nrc.ca >you write:
  > I raised this point because I thought it might be a mistake for the assembl
  > er
  > not to make all branches with R_PCREL_CALL.  At the present time, short
  > branches appear to be built directly by the assembler and don't have any
  > relocation data.  To find these, the linker would have to scan the actual
  > code around an addil that was being removed.
It isn't a mistake to the best of my knowledge -- it already has to scan
the code to find the %r1 uses, pc-relative conditional branches and the
like.


jeff

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

>   > I raised this point because I thought it might be a mistake for the assembl
>   > er
>   > not to make all branches with R_PCREL_CALL.  At the present time, short
>   > branches appear to be built directly by the assembler and don't have any
>   > relocation data.  To find these, the linker would have to scan the actual
>   > code around an addil that was being removed.
> It isn't a mistake to the best of my knowledge -- it already has to scan
> the code to find the %r1 uses, pc-relative conditional branches and the
> like.

Yes, it seems ok.  I just did a gcc bootstrap with -Wl,-O.

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> On Sat, 23 Sep 2000, John David Anglin wrote:
> 
> > Look's like it fixes the problem, although I can't do a complete test now.
> 
> Thanks.  I'll commit the change, which goes back to the old SOM handling
> for external and weak syms, on the strength of your say-so.  Incidentally,
> dhd's original patch was surrounded with #ifdef OBJ_ELF, but I changed
> it...

I looked at the code in hppa_fix_adjustable and hppa_force_relocation
and I think the fix is wrong.  The external and weak checks should also
be done for SOM.  Dynamic linking involving weak symbols under hpux is
not well tested.  This is used with libstdc++ but currently building
a shared libstdc++ doesn't work well with the archive format of libgcc.

Possibly, the situation which caused the fault here is special--a function
recursively calling itself.  However, I think the correct fix is for
relocation information to be output for the call.  The assembler should
not use an assembler generated pc-relative offset for calling weak or
external symbols.  It should only use this form for local symbols within
a function and as noted in a previous email this might present problems
for addil removal.  I will try and check whether it is or not.

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Sun, 24 Sep 2000, John David Anglin wrote:

> The external and weak checks should also be done for SOM.

Agreed.  However, adding the checks and emitting relocs caused problems,
so until someone figures out why, I've gone back to the old SOM code.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> On Sun, 24 Sep 2000, John David Anglin wrote:
> 
> > The external and weak checks should also be done for SOM.
> 
> Agreed.  However, adding the checks and emitting relocs caused problems,
> so until someone figures out why, I've gone back to the old SOM code.

The problem is now clear to me.  The fix that I sent seems to work ok
under hpux.  Binutils now has no failures and I did a complete bootstrap
of gcc with it.

The patch that I sent causes all recursive calls to have relocation data.  
This may not be optimal as recursive calls shouldn't need relocation
data.  However, the testing needed to determine if a call is recursive are
more complicated than what I submitted.  As far as I could tell, branches
within procedures still have no relocation data.  It is only branches
to procedure entry points that present a problem.

If you want to eliminate the relocation data for recursive calls, then
for example, the weak/external check must include a check to see if
this is not a recursive call to the symbol.  Further, in the old code,
long branches always have relocation data.  This would also have to be
fixed.

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> On Sat, 23 Sep 2000, John David Anglin wrote:
> 
> > Look's like it fixes the problem, although I can't do a complete test now.
> 
> Thanks.  I'll commit the change, which goes back to the old SOM handling
> for external and weak syms, on the strength of your say-so.  Incidentally,
> dhd's original patch was surrounded with #ifdef OBJ_ELF, but I changed
> it...

Using the current source with the above patch and the tree patches which
I just submitted which were necessary to get things to build with the
native compiler, I had one testsuite failure:

...
a.out:     file format som

RELOCATION RECORDS FOR [$CODE$]:
OFFSET   TYPE              VALUE
00000000 R_ENTRY           *ABS*+0x08010010
0000000c R_DP_RELATIVE     $DATA$+0x00000010
00000010 R_DP_RELATIVE     $DATA$+0x00000010
00000028 R_EXIT            *ABS*+0x00000008


RELOCATION RECORDS FOR [$DATA$]: (none)

FAIL: reduce3.s: Test even more relocation reductions (part 2)

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Sun, 24 Sep 2000, John David Anglin wrote:

> Using the current source with the above patch and the tree patches which
> I just submitted which were necessary to get things to build with the
> native compiler, I had one testsuite failure:
> FAIL: reduce3.s: Test even more relocation reductions (part 2)

That's because I removed too much from hppa_fix_adjustable with the last
patch.  Oops.  Prior to 2000-09, we had a a test for S_IS_EXTERNAL.

-- 
Linuxcare.  Support for the Revolution.

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> Since the linker hasn't changed, I would have to guess that there is a
> relocation problem with respect to the above call.  However, when I
> include the relocation info in the assembly dump of emit-rtl.o, things
> appear normal:
> 
>  20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
> 		 	20c: R_PCREL_CALL       reset_used_flags+0x40000000

The problem is the `0' in the above.  It should be 

20c:   e8 5f 1b dd     b,l 214 <reset_used_flags+0x214>,rp
 		       20c: R_PCREL_CALL       reset_used_flags+0x40000000

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Fri, 22 Sep 2000, John David Anglin wrote:

> > Since the linker hasn't changed, I would have to guess that there is a
> > relocation problem with respect to the above call.  However, when I
> > include the relocation info in the assembly dump of emit-rtl.o, things
> > appear normal:
> > 
> >  20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
> > 		 	20c: R_PCREL_CALL       reset_used_flags+0x40000000
> 
> The problem is the `0' in the above.  It should be 
> 
> 20c:   e8 5f 1b dd     b,l 214 <reset_used_flags+0x214>,rp
>  		       20c: R_PCREL_CALL       reset_used_flags+0x40000000

Hmm, does reverting my recent change to hppa_force_relocation cure the
problem?  Or even a not-so-recent change to hppa_fix_adjustable?

-- 
Linuxcare.  Support for the Revolution.

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

> > Since the linker hasn't changed, I would have to guess that there is a
> > relocation problem with respect to the above call.  However, when I
> > include the relocation info in the assembly dump of emit-rtl.o, things
> > appear normal:
> > 
> >  20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
> > 		 	20c: R_PCREL_CALL       reset_used_flags+0x40000000
> 
> The problem is the `0' in the above.  It should be 
> 
> 20c:   e8 5f 1b dd     b,l 214 <reset_used_flags+0x214>,rp
>  		       20c: R_PCREL_CALL       reset_used_flags+0x40000000

Reverting to a snapshot from 20000906, there was no relocation information
printed by objdump for the call:

 20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
 210:   08 00 02 40     nop

A similar recursive call in copy_rtx_if_shared has the relocation info:

458:   e8 40 00 00     b,l 460 <copy_rtx_if_shared+0x460>,rp
                       458: R_PCREL_CALL       copy_rtx_if_shared+0x40000000
45c:   08 00 02 40     nop

Checking the new linked version of cc1, the code looks ok for the call to
reset_used_flags.  So, it appears that the R_PCREL_CALL relocation was added
incorrectly by the new version of gas to a "local" branch with its offset
setup by the assembler.

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

Re: gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[Alan Modra]

On Sat, 23 Sep 2000, John David Anglin wrote:

> Reverting to a snapshot from 20000906, there was no relocation information
> printed by objdump for the call:
> 
>  20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
>  210:   08 00 02 40     nop
> 
> A similar recursive call in copy_rtx_if_shared has the relocation info:
> 
> 458:   e8 40 00 00     b,l 460 <copy_rtx_if_shared+0x460>,rp
>                        458: R_PCREL_CALL       copy_rtx_if_shared+0x40000000
> 45c:   08 00 02 40     nop
> 
> Checking the new linked version of cc1, the code looks ok for the call to
> reset_used_flags.  So, it appears that the R_PCREL_CALL relocation was added
> incorrectly by the new version of gas to a "local" branch with its offset
> setup by the assembler.

Err, it really look like I'm to blame.  Does this patch fix the problem?

Index: config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.66
diff -u -p -r1.66 tc-hppa.c
--- tc-hppa.c	2000/09/18 12:36:03	1.66
+++ tc-hppa.c	2000/09/23 06:04:34
@@ -8310,6 +8310,10 @@ hppa_fix_adjustable (fixp)
   if (fixp->fx_r_type == (int) R_PARISC_GNU_VTINHERIT
       || fixp->fx_r_type ==  (int) R_PARISC_GNU_VTENTRY)
     return 0;
+
+  if (fixp->fx_addsy && (S_IS_EXTERNAL (fixp->fx_addsy)
+			 || S_IS_WEAK (fixp->fx_addsy)))
+    return 0;
 #endif
 
   /* Reject reductions of symbols in sym1-sym2 expressions when
@@ -8372,10 +8376,6 @@ hppa_fix_adjustable (fixp)
       || hppa_fix->fx_r_field == e_lpsel)
     return 0;
 
-  if (fixp->fx_addsy && (S_IS_EXTERNAL (fixp->fx_addsy)
-			 || S_IS_WEAK (fixp->fx_addsy)))
-    return 0;
-
   /* Reject absolute calls (jumps).  */
   if (hppa_fix->fx_r_type == R_HPPA_ABS_CALL)
     return 0;
@@ -8414,13 +8414,13 @@ hppa_force_relocation (fixp)
   if (fixp->fx_r_type == (int) R_PARISC_GNU_VTINHERIT
       || fixp->fx_r_type == (int) R_PARISC_GNU_VTENTRY)
     return 1;
-#endif
 
   /* Ensure we emit a relocation for global symbols so that dynamic
      linking works.  */
   if (fixp->fx_addsy && (S_IS_EXTERNAL (fixp->fx_addsy)
 			 || S_IS_WEAK (fixp->fx_addsy)))
     return 1;
+#endif
 
   /* It is necessary to force PC-relative calls/jumps to have a relocation
      entry if they're going to need either a argument relocation or long

-- 
Linuxcare.  Support for the Revolution.

gas 2.10.91 from 20000920 cvs is broken under hpux 10.20

[John David Anglin]

In trying to resolve this bug which has been noted for a few days on the
gcc-bugs list,

./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa1.1-hp-hpux10.20/include -O2   -DIN_GCC    -g -W -Wall  -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes  -Wno-long-long -isystem ./include  -fPIC -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -DUSE_COLLECT2 -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o
../../gcc/libgcc2.c: In function `__muldi3':
../../gcc/libgcc2.c:199: Internal error: Segmentation fault.
   Please submit a full bug report.
   See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

I found that the segmentation fault on my machine occurs in emit-rtl.c.
The following code in reset_used_flags is incorrectly linked into cc1
and ultimately causes the fault:

        ldo 4(%r19),%r19
	addl %r19,%r21,%r20
	ldw 0(%r20),%r26
	.CALL ARGW0=GR
	bl reset_used_flags,%r2
	nop
	.stabn 68,0,2010,L$M646-reset_used_flags

The disassembly of emit-rtl.o with objdump looks ok

 200:   36 73 00 08     ldo 4(r19),r19
 204:   0a b3 0a 14     add,l r19,r21,r20
 208:   0e 80 10 9a     ldw  0(sr0,r20),r26
 20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
 210:   08 00 02 40     nop

but when the module is linked the `b,l' to reset_used_flags changes to
a `b,l' into the middle of copy_rtx_if_shared (the previous function)

0x1d84d0 <reset_used_flags+512>:        ldo 4(r19),r19
0x1d84d4 <reset_used_flags+516>:        add,l r19,r21,r20
0x1d84d8 <reset_used_flags+520>:        ldw  0(sr0,r20),r26
0x1d84dc <reset_used_flags+524>:
    b,l 0x1d80bc <copy_rtx_if_shared+700>,rp
0x1d84e0 <reset_used_flags+528>:        nop

Since the linker hasn't changed, I would have to guess that there is a
relocation problem with respect to the above call.  However, when I
include the relocation info in the assembly dump of emit-rtl.o, things
appear normal:

 20c:   e8 5f 1b dd     b,l 0 <reset_used_flags>,rp
		 	20c: R_PCREL_CALL       reset_used_flags+0x40000000

Thus, I am not sure what's going on.

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