Re: Duplicate symbols in recent cvs source

Re: Duplicate symbols in recent cvs source

[John David Anglin]

After apply the supplied patch to fix the duplicate symbol problem,
there are now some unresolved symbols.  I think the problem is that
epoc-pe-arm and epoc-pei-arm are not in the Makefile.

1031 (hiauly1)dave> ./ar --help
/lib/dld.sl: Unresolved symbol: arm_epoc_pe_little_vec (data)  from /xxx/gnu/bin
utils-2.9.4/bfd/.libs/libbfd.sl
/lib/dld.sl: Unresolved symbol: arm_epoc_pei_little_vec (data)  from /xxx/gnu/bi
nutils-2.9.4/bfd/.libs/libbfd.sl
/lib/dld.sl: Unresolved symbol: arm_epoc_pe_big_vec (data)  from /xxx/gnu/binuti
ls-2.9.4/bfd/.libs/libbfd.sl
/lib/dld.sl: Unresolved symbol: arm_epoc_pei_big_vec (data)  from /xxx/gnu/binut
ils-2.9.4/bfd/.libs/libbfd.sl


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

Re: Duplicate symbols in recent cvs source

[John David Anglin]

> 
> After apply the supplied patch to fix the duplicate symbol problem,
> there are now some unresolved symbols.  I think the problem is that
> epoc-pe-arm and epoc-pei-arm are not in the Makefile.

After adding these, there are another similar set of duplicate
symbols:

/bin/ld: Duplicate symbol "bfd_arm_pe_get_bfd_for_interworking", files epoc-pe-a
rm.lo and pe-arm.lo
/bin/ld: Duplicate symbol "bfd_arm_pe_process_before_allocation", files epoc-pe-
arm.lo and pe-arm.lo
/bin/ld: Duplicate symbol "bfd_arm_pe_allocate_interworking_sections", files epo
c-pe-arm.lo and pe-arm.lo
/bin/ld: Duplicate symbols are not allowed in shared libraries

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

#error ELF_MAXPAGESIZE is not defined

[John David Anglin]

Another one from today's source:

gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -DHOST_HPPAHPUX -DHPUX_CORE -I. -I
. -I./../include -I./../intl -I../intl -O3 -c  -fPIC -DPIC elf32-m88k.c -o .libs
/elf32-m88k.lo
In file included from elf32-m88k.c:35:
elf32-target.h:205: #error ELF_MAXPAGESIZE is not defined
make[3]: *** [elf32-m88k.lo] Error 1

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

Errors compiling coff-tic54x.c from todays CVS source

[John David Anglin]

gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -DHOST_HPPAHPUX -DHPUX_CORE -I. -I. -I./../include -I./../intl -I../intl -W -Wall -O3 -c coff-tic54x.c  -fPIC -DPIC -o .libs/coff-tic54x.lo
In file included from coffcode.h:310,
                 from coff-tic54x.c:296:
coffswap.h: In function `coff_swap_filehdr_in':
coffswap.h:293: `F_LDPAGE' undeclared (first use in this function)
coffswap.h:293: (Each undeclared identifier is reported only once
coffswap.h:293: for each function it appears in.)
coffswap.h: In function `coff_swap_scnhdr_in':
coffswap.h:842: structure has no member named `s_page'
coffswap.h: In function `coff_swap_scnhdr_out':
coffswap.h:917: structure has no member named `s_page'
coffswap.h:917: structure has no member named `s_page'
coffswap.h:917: warning: left-hand operand of comma expression has no effect
In file included from coff-tic54x.c:296:
coffcode.h: In function `coff_set_custom_section_alignment':
coffcode.h:1426: warning: comparison of unsigned expression < 0 is always false
coffcode.h: In function `coff_set_arch_mach_hook':
coffcode.h:1765: warning: `arch' might be used uninitialized in this function
coff-tic54x.c: At top level:
coff-tic54x.c:423: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:423: initializer element is not constant
coff-tic54x.c:423: (near initialization for `tic54x_coff0_vec.object_flags')
coff-tic54x.c:467: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:467: initializer element is not constant
coff-tic54x.c:467: (near initialization for `tic54x_coff0_beh_vec.object_flags')
coff-tic54x.c:512: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:512: initializer element is not constant
coff-tic54x.c:512: (near initialization for `tic54x_coff1_vec.object_flags')
coff-tic54x.c:557: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:557: initializer element is not constant
coff-tic54x.c:557: (near initialization for `tic54x_coff1_beh_vec.object_flags')
coff-tic54x.c:602: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:602: initializer element is not constant
coff-tic54x.c:602: (near initialization for `tic54x_coff2_vec.object_flags')
coff-tic54x.c:647: `HAS_LOAD_PAGE' undeclared here (not in a function)
coff-tic54x.c:647: initializer element is not constant
coff-tic54x.c:647: (near initialization for `tic54x_coff2_beh_vec.object_flags')
make[3]: *** [coff-tic54x.lo] Error 1
make[3]: Leaving directory `/xxx/gnu/binutils-2.9.5/bfd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/xxx/gnu/binutils-2.9.5/bfd'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/xxx/gnu/binutils-2.9.5/bfd'
make: *** [all-bfd] Error 2

-- 
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]

> 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.

[Patch]: 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...

Here is what I think is the correct fix.  The above change is reverted
so that the test for external and weak is done for both ELF and SOM.  This
fixes the test failure on reduce3.s.  It is possible that the weak
checks are unnecessary, particularly for hppa_fix_adjustable.  It appears
that adjust_reloc_syms does it own check for weak syms.

The fix for the problem is to change arg_reloc_stub_needed so that stubs
are generated for recursive calls.

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

2000-09-24  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	config/tc-hppa.c (arg_reloc_stub_needed): Stub is needed even when
	caller and callee are the same.
	(hppa_fix_adjustable): Do the external and weak checks for both ELF
	and SOM.
	(hppa_force_relocation): Likewise.

--- config/tc-hppa.c.orig	Sun Sep 24 13:01:23 2000
+++ config/tc-hppa.c	Sun Sep 24 17:52:40 2000
@@ -4323,8 +4323,7 @@
 }
 
 #if defined (OBJ_SOM) || defined (ELF_ARG_RELOC)
-#define arg_reloc_stub_needed(CALLER, CALLEE) \
-  ((CALLEE) && (CALLER) && ((CALLEE) != (CALLER)))
+#define arg_reloc_stub_needed(CALLER, CALLEE) ((CALLEE) && (CALLER))
 #else
 #define arg_reloc_stub_needed(CALLER, CALLEE) 0
 #endif
@@ -8310,11 +8309,11 @@
   if (fixp->fx_r_type == (int) R_PARISC_GNU_VTINHERIT
       || fixp->fx_r_type ==  (int) R_PARISC_GNU_VTENTRY)
     return 0;
+#endif
 
   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
      the fixup will occur in a CODE subspace.
@@ -8414,13 +8413,13 @@
   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

Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux

[John David Anglin]

> When the function `int f(char *p)' is called recursively, I see the following
> in md_apply_fix when the function is called:
> 
> Breakpoint 1, md_apply_fix (fixP=0x40026f10, valp=0x7b03ab84)
>     at ./config/tc-hppa.c:4412
> 4412          if ((fmt == 12 || fmt == 17 || fmt == 22)
> (gdb) p fixP->fx_pcrel
> $3 = 1
> (gdb) p (((obj_symbol_type *) symbol_get_bfdsym (fixP->fx_addsy))->tc_data.ap.hppa_arg_reloc)
> $4 = 257
> (gdb) p hppa_fixP->fx_arg_reloc
> $5 = 256
> 
> It doesn't see right that a simple function such as the one above should
> need an argument relocation stub.  If I change the return type to void, then
> both values are 256 and no stub is needed.   I haven't been able to 
> find where the bits for fx_arg_reloc are defined.  Does this seem right?

There is a problem here but it doesn't appear to be with binutils.  Rather,
it is with gcc.  The .EXPORT statement generated for the above function is:

        .EXPORT f,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR

However, the .CALL generated doesn't include RTNVAL=GR:

        .CALL ARGW0=GR

Since the .CALL is missing a RTNVAL=GR, the two don't match and an argument
relocation stub is being generated for all functions with a return in a GR.

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

Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux

[John David Anglin]

> > It doesn't see right that a simple function such as the one above should
> > need an argument relocation stub.  If I change the return type to void, then
> > both values are 256 and no stub is needed.   I haven't been able to 
> > find where the bits for fx_arg_reloc are defined.  Does this seem right?
> 
> There is a problem here but it doesn't appear to be with binutils.  Rather,
> it is with gcc.  The .EXPORT statement generated for the above function is:
> 
>         .EXPORT f,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR
> 
> However, the .CALL generated doesn't include RTNVAL=GR:
> 
>         .CALL ARGW0=GR
> 
> Since the .CALL is missing a RTNVAL=GR, the two don't match and an argument
> relocation stub is being generated for all functions with a return in a GR.

Changed my mind about the problem being in gcc.  The default when an
argument description is omitted from a .CALL statement is ARG = NO.
NO means the argument cannot be relocated.  Thus, the definition of
arg_reloc_stub_needed needs to be fixed to check all four args and the
return separately.

A possible fix is attached below.  Note there is another small fix
to pa_align as well.

There is one test failure: reduce.s.  The new code no longer generates
a R_PCREL_CALL call to foo.  However, I believe that this is correct
since foo is `static' (ie., not exported) and an argument relocation
stub is not required for the call.

--- reduce.o.as.reloc	Tue Sep 26 16:15:18 2000
+++ reduce.o.as-new.reloc	Tue Sep 26 16:15:32 2000
@@ -1,5 +1,5 @@
 
-reduce.o.as:     file format som
+reduce.o.as-new:     file format som
 
 RELOCATION RECORDS FOR [$CODE$]:
 OFFSET   TYPE              VALUE 
@@ -9,7 +9,6 @@
 00000008 R_ENTRY           *ABS*+0x08000008
 00000008 R_CODE_ONE_SYMBOL  $CODE$+0x00000004
 0000000c R_CODE_ONE_SYMBOL  $CODE$+0x00000004
-00000014 R_PCREL_CALL      foo+0x40000000
 00000028 R_EXIT            *ABS*+0x00000010
 
Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-09-26  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	* config/tc-hppa.c (arg_reloc_stub_needed): Use
	pa_arg_reloc_stub_needed to check arguments and return separately.
	(pa_arg_reloc_stub_needed): New function.
	(arg_reloc_check): New macro.
	(pa_align): Declare argument `bytes'.

--- config/tc-hppa.c.alan	Mon Sep 25 15:24:54 2000
+++ config/tc-hppa.c	Tue Sep 26 15:27:28 2000
@@ -4323,8 +4323,24 @@
 }
 
 #if defined (OBJ_SOM) || defined (ELF_ARG_RELOC)
+#define arg_reloc_check(a, b, m) \
+  (((a) & (m)) && ((b) & (m)) && (((a) & (m)) != ((b) & (m))))
+
+/* Check all arguments and return value to see if caller and callee
+   agree on their location. */
+static int
+pa_arg_reloc_stub_needed (caller, callee)
+  unsigned int caller, callee;
+{
+  return (arg_reloc_check (caller, callee, 0x003)
+    || arg_reloc_check (caller, callee, 0x00c)
+    || arg_reloc_check (caller, callee, 0x030)
+    || arg_reloc_check (caller, callee, 0x0c0)
+    || arg_reloc_check (caller, callee, 0x300));
+}
+
 #define arg_reloc_stub_needed(CALLER, CALLEE) \
-  ((CALLEE) && (CALLER) && ((CALLEE) != (CALLER)))
+  pa_arg_reloc_stub_needed ((CALLER), (CALLEE))
 #else
 #define arg_reloc_stub_needed(CALLER, CALLEE) 0
 #endif
@@ -5831,6 +5847,7 @@
    alignment of the subspace if necessary.  */
 static void
 pa_align (bytes)
+  int bytes;
 {
   /* We must have a valid space and subspace.  */
   pa_check_current_space_and_subspace ();

Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux

[Alan Modra]

On Tue, 26 Sep 2000, John David Anglin wrote:

> Changed my mind about the problem being in gcc.  The default when an
> argument description is omitted from a .CALL statement is ARG = NO.
> NO means the argument cannot be relocated.  Thus, the definition of
> arg_reloc_stub_needed needs to be fixed to check all four args and the
> return separately.
> 
> A possible fix is attached below.  Note there is another small fix
> to pa_align as well.

Thanks.  Your analysis looks correct.

Hmm, let's see

#define nonzero_dibits(x) \
  ((x) | (((x) & 0x55555555) << 1) | (((x) & 0xAAAAAAAA) >> 1))
#define arg_reloc_stub_needed(CALLER, CALLEE) \
  (((CALLER) ^ (CALLEE)) & nonzero_dibits (CALLER) & nonzero_dibits (CALLEE))

should work too.

-- 
Linuxcare.  Support for the Revolution.

Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux

[John David Anglin]

> > A possible fix is attached below.  Note there is another small fix
> > to pa_align as well.
> 
> Thanks.  Your analysis looks correct.
> 
> Hmm, let's see
> 
> #define nonzero_dibits(x) \
>   ((x) | (((x) & 0x55555555) << 1) | (((x) & 0xAAAAAAAA) >> 1))
> #define arg_reloc_stub_needed(CALLER, CALLEE) \
>   (((CALLER) ^ (CALLEE)) & nonzero_dibits (CALLER) & nonzero_dibits (CALLEE))
> 
> should work too.

Pretty tricky.  I used a function rather than a macro because of the function
evaluation needed for the caller symbol_arg_reloc_info (fixP->fx_addsy).
However, I didn't look at optimized code so maybe the optimizer will
eliminate the multiple calls.

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

Re: [Patch]: Re: gas 2.10.91 from 20000920 cvs is broken under hpux

[Alan Modra]

On Tue, 26 Sep 2000, John David Anglin wrote:

> There is one test failure: reduce.s.  The new code no longer generates
> a R_PCREL_CALL call to foo.  However, I believe that this is correct

Fixed like this.

gas/testsuite/ChangeLog
	* gas/hppa/reloc/reduce.s: Modify .PARAM so we need an arg reloc.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Index: gas/hppa/reloc/reduce.s
===================================================================
RCS file: /cvs/src/src/gas/testsuite/gas/hppa/reloc/reduce.s,v
retrieving revision 1.2
diff -u -p -r1.2 reduce.s
--- reduce.s	1999/08/30 21:00:59	1.2
+++ reduce.s	2000/09/28 08:34:06
@@ -4,7 +4,7 @@
 
 	.code
 	.align 4
-	.PARAM foo,RTNVAL=GR
+	.PARAM foo,ARGW0=FR
 foo:
 	.PROC
 	.CALLINFO FRAME=0,NO_CALLS

Re: vax quad.exp testsuite failure

[John David Anglin]

> Note the different file offsets for the data section.  Also, if I add a
> `nop' to the test, objdump doesn't print it:
> 
> bash-2.04# ../../../../objdir/gas/as-new -o quad.o quad.s
> bash-2.04# od -x quad.o
> 0000000 0107 0000 000c 0000 0000 0000 0000 0000
> 0000020 0000 0000 0000 0000 0000 0000 0000 0000
> 0000040 8f7d 5678 1234 ccdd aabb 0150
> 0000054
> bash-2.04# ../../../../objdir/binutils/objdump -hd quad.o
> 
> quad.o:     file format a.out
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0000000c  00000000  00000000  00000020  2**2
> 		  CONTENTS, ALLOC, LOAD, CODE
>   1 .data         00000000  0000000c  0000000c  0000002c  2**2
> 		  CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          00000000  0000000c  0000000c  00000000  2**2
> 		  ALLOC
> ../../../../objdir/binutils/objdump: quad.o: no symbols
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:   7d 8f 78 56     movq $0xaabbccdd12345678,r0
>    4:   34 12 dd cc
>    8:   bb aa 50
>    b:   Address 0xb is out of bounds.

Here is a fix to correct the disassembly of quad.o by objdump.

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

2001-03-14  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* vax-dis.c (print_insn_vax): Only fetch two bytes if the info buffer
	has more than one byte left to read.

--- vax-dis.c.orig	Fri Apr 14 00:16:58 2000
+++ vax-dis.c	Wed Mar 14 17:40:45 2001
@@ -126,7 +126,18 @@
       return -1;
     }
 
-  FETCH_DATA (info, buffer + 2);
+  /* Check if the info buffer has more than one byte left since
+     the last opcode might be a single byte with no argument data.  */
+  if (info->buffer_length - (memaddr - info->buffer_vma) > 1)
+    {
+      FETCH_DATA (info, buffer + 2);
+    }
+  else
+    {
+      FETCH_DATA (info, buffer + 1);
+      buffer[1] = 0;
+    }
+
   for (votp = &votstrs[0]; votp->name[0]; votp++)
     {
       register vax_opcodeT opcode = votp->detail.code;

Re: vax quad.exp testsuite failure

[Alan Modra]

On Wed, 14 Mar 2001, John David Anglin wrote:

> Here is a fix to correct the disassembly of quad.o by objdump.

Can I suggest taking a look at the way the i386-dis.c does this?
The reason being that your patch only catches one place where
FETCH_DATA can fail.  What about NEXTWORD, NEXTLONG?

Alan Modra
-- 
Linuxcare

Re: vax quad.exp testsuite failure

[John David Anglin]

> On Wed, 14 Mar 2001, John David Anglin wrote:
> 
> > Here is a fix to correct the disassembly of quad.o by objdump.
> 
> Can I suggest taking a look at the way the i386-dis.c does this?
> The reason being that your patch only catches one place where
> FETCH_DATA can fail.  What about NEXTWORD, NEXTLONG?

I can't do this for a couple of weeks.  However, the problem
may only occur reading the opcode.  After that if the insn has
argument data, the length to fetch should be determined by the
mode for each operand.

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

Re: vax quad.exp testsuite failure

[John David Anglin]

> The following failure occurs with the cvs source from 20010202 under vax-ultrix:
> 
> Running /xxx/gnu/binutils-2.10.91/gas/testsuite/gas/vax/quad.exp ...
> GAS LISTING /xxx/gnu/binutils-2.10.91/gas/testsuite/gas/vax/quad.s
>         page 1
> 
> 
>    1                            .text
>    2 0000 7D8F7856              movq $0xaabbccdd12345678,r0
>    2      3412DDCC
>    2      BBAA50
> FAIL: quad.s: quadword immediate values

This patch fixes the expected test result.

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

2001-01-14  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* gas/vax/quad.exp: Correct expected result.

--- gas/vax/quad.exp.orig	Mon May  3 03:28:53 1999
+++ gas/vax/quad.exp	Wed Mar 14 16:30:48 2001
@@ -8,7 +8,7 @@
 	expect {
 	    -re "^ +2\[ \t\]+0000+ 7D8F7856\[ \t\]+movq\[^\n\]*\n" { set x1 1 }
 	    -re "^ +2\[ \t\]+3412DDCC\[^\n\]*\n"		   { set x2 1 }
-	    -re "^ +2\[ \t\]+BBAA5001\[ \t\]*\r\n"		   { set x3 1 }
+	    -re "^ +2\[ \t\]+BBAA50\[ \t\]*\r\n"		   { set x3 1 }
 	    -re "\[^\n\]*\n"				{ }
 	    timeout				{ perror "timeout\n"; break }
 	    eof					{ break }

Re: [patch] tc-*.[ch]: Fix formatting.

[Alan Modra]

On Sun, Jul 22, 2001 at 10:41:54PM +0000, Kazu Hirata wrote:
> 
> Attached is a patch to fix formatting of tc-*.[ch].  OK to apply?

OK.

> --- tc-m68k.c	2001/07/18 10:25:57	1.28
> +++ tc-m68k.c	2001/07/22 18:27:20
> @@ -257,9 +257,9 @@
>       const struct m68k_incant *opcode;
>  {
>    int z;
> -  for(z=the_ins.numo;z>opcode->m_codenum;--z)
> +  for (z=the_ins.numo;z>opcode->m_codenum;--z)

Since you're reformatting this line
     for (z = the_ins.numo; z > opcode->m_codenum; --z)

>      the_ins.opcode[z]=the_ins.opcode[z-1];
> -  for(z=0;z<the_ins.nrel;z++)
> +  for (z=0;z<the_ins.nrel;z++)
     for (z = 0; z < the_ins.nrel; z++)

Re: [patch] s390-dis.c: Fix formatting.

[Alan Modra]

On Sun, Jul 22, 2001 at 10:41:55PM +0000, Kazu Hirata wrote:
> 	* s390-dis.c: Fix formatting.

OK

Re: [patch] *-dis.c: Fix formatting.

[Alan Modra]

On Mon, Jul 23, 2001 at 10:49:04PM +0000, Kazu Hirata wrote:
> 	* m68k-dis.c: Fix formatting.
> 	* pj-dis.c: Likewise.
> 	* z8k-dis.c: Likewise.

OK, thanks.  A few extra nits below.

> --- z8k-dis.c	2001/06/06 17:01:35	1.6
> +++ z8k-dis.c	2001/07/23 14:44:22
> @@ -339,15 +335,17 @@
>  	    {
>  	    case ARG_DISP16:
>                instr_data->displacement = instr_data->insn_start + 4 +
> -                (signed short)(instr_word & 0xffff);
> +                (signed short) (instr_word & 0xffff);
>  	      nibl_count += 3;
>  	      break;
>  	    case ARG_DISP12:
> -              if (instr_word & 0x800) {  /* neg. 12 bit displacement */
> -                instr_data->displacement = instr_data->insn_start + 2 -
> -                  (signed short)((instr_word & 0xfff) | 0xf000) * 2;
> -              }
> -              else {
> +              if (instr_word & 0x800)
> +		{  /* neg. 12 bit displacement */

I'm not too sure exactly what the coding standard says about the above,
but most other places don't put the comment with the opening brace.
Better to split this to two lines, I think.

> +		  instr_data->displacement = instr_data->insn_start + 2 -
> +		    (signed short) ((instr_word & 0xfff) | 0xf000) * 2;

Don't break a line to leave a trailing operator.

> +		}
> +              else
> +		{
>                  instr_data->displacement = instr_data->insn_start + 2 - (instr_word & 0x0fff) * 2;

This line should be split too.

>                }
>  	      nibl_count += 2;

Re: [patch] *-dis.c: Fix formatting. (2nd set)

[Alan Modra]

On Tue, Jul 24, 2001 at 02:15:09AM +0000, Kazu Hirata wrote:
> 	* alpha-dis.c: Fix formatting.
> 	* cris-dis.c: Likewise.
> 	* m10300-dis.c: Likewise.
> 	* tic54x-dis.c: Likewise.

OK.

Re: [patch] d?0v-dis.c: Fix formatting.

[Alan Modra]

On Tue, Jul 24, 2001 at 10:40:13PM +0000, Kazu Hirata wrote:
> 	* d10v-dis.c: Fix formatting.
> 	* d30v-dis.c: Likewise.

OK

Re: [patch] i386-dis.c: Fix formatting.

[Alan Modra]

On Sun, Jul 29, 2001 at 02:30:53AM +0000, Kazu Hirata wrote:
> 	* i386-dis.c: Fix formatting.

OK.  Thanks.

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[John David Anglin]

> I have looked a bit more into this problem and it appears more difficult
> to solve than first thought.  We can't just provide these symbols because
> they are provided by the dynamic loader.  Because static linking still
> produces a "dynamic" binary, we need to allow undefined dynamic-loader
> absolute symbols in static links.  This is what the HP linker does.
> If we produced a true static binary, the linker would have to provide
> these symbols.

I have done some debugging of the problem.  The segmentation fault isn't
related to the linker defined symbols under hppa64-hp-hpux11.11.

The following program seg faults when it exits:

main () { exit (0); }

bash-2.05$ gcc -g -static -o main main.c
bash-2.05$ ./main
Segmentation fault (core dumped)

The problem is this code in the exitcu.o module:

   8:   2b 60 00 00     addil 0,dp,%r1
			8: R_PARISC_LTOFF_FPTR21L       do_exitcu
   c:   50 3a 00 00     ldd 0(r1),r26
			c: R_PARISC_LTOFF_FPTR14DR      do_exitcu

When linked with gnu ld, r26 ends up with actual address of "do_exitcu".
However, r26 should contain the address of the .opd entry for "do_exitcu".  

I don't fully understand the code in elf64-hppa.c but it seems that
there is something tricky going on with respect to the values of symbols
for which there are .opd entries.  Does this ring any bells as to
what's going on?

I also noticed that HP makes the .opd section readonly.

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

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[John David Anglin]

> >  > Thus, The problem must be that we are doing the relocations for
> >  > R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_FPTR14DR incorrectly.
> > Maybe.
> 
> Here is a fix.  My simple static link now runs correctly and I have confirmed
> that do_exitcu is called correctly during exit.

There appears to be a problem but I don't know what.  I can't bootstrap
gcc with the new tools.

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

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[law]

In message <200202130004.g1D04Pb2027114@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > >  > Thus, The problem must be that we are doing the relocations for
 > > >  > R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_FPTR14DR incorrectly.
 > > > Maybe.
 > > 
 > > Here is a fix.  My simple static link now runs correctly and I have confir
 > med
 > > that do_exitcu is called correctly during exit.
 > 
 > There appears to be a problem but I don't know what.  I can't bootstrap
 > gcc with the new tools.
Could you bootstrap before your ld change?  

I have a bootstrap of an older toolchain started with your ld patch, but
it'll take a long time to finish (and make the box otherwise unusable), so
if it's not worthwhile, then I'd prefer to kill that test.

jeff

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[John David Anglin]

Here is a revised version of the patch to fix the '-static' linking
problems found under hppa64-hp-hpux11.X.  The issues fixed are:

  1) Dynamic loader symbols need to be ignored.
  2) Various problems with respect to .opd creation and the DLT entries
     for local symbols are fixed.  The most serious issues were that sometimes
     we didn't create the DLT entry, and the addend was being used incorrectly.
  3) In reviewing the code, I noted that the selector usage for various
     relocations was not consistent with that specified in the HP
     "Processor-Specific ELF for PA-RISC, Version 1.43" document.
     This involved changing various relocations to L/R selectors
     from LR/RR selectors.  I have updated the assembler LR/RR table to
     reflect this change.  I believe that with this patch selector
     usage now pretty much conforms to that specified in the above document.

I have done bootstraps and checks of gcc using these tools for
hppa64-hp-hpux11.00 and hppa64-hp-hpux11.11.  I have also been doing
hppa-linux builds using tools with this patch for the past couple
of weeks.  Oh, I can now link programs with '-static'.

Please install if OK.

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

2002-02-26  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* bfd/elf-hppa.h (elf_hppa_is_dynamic_loader_symbol): New function.
	(elf_hppa_relocate_section): Ignore undefined dynamic loader symbols.
	(elf_hppa_final_link_relocate): Correct relocations for indirect
	references to local data through the DLT.  Fix .opd creation for
	local symbols using R_PARISC_LTOFF_FPTR32 and R_PARISC_FPTR64
	relocations.  Use e_lsel selector for R_PARISC_DLTIND21L,
	R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_TP21L as per
	"Processor-Specific ELF for PA_RISC, Version 1.43" document.
	Similarly, use e_rsel for DLT and LTOFF 'R' relocations.
	* bfd/elf32-hppa.c (final_link_relocate): Revise relocation selectors
	as per "Processor-Specific ELF for PA_RISC, Version 1.43" document.
	* gas/config/tc-hppa.c (md_apply_fix3): Add cast.
	(hppa_fix_adjustable): Adjust list of selectors using e_lrsel and
	e_rrsel.

Index: bfd/elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.53
diff -u -3 -p -r1.53 elf-hppa.h
--- bfd/elf-hppa.h	2002/02/12 11:08:27	1.53
+++ bfd/elf-hppa.h	2002/02/13 19:28:25
@@ -75,6 +75,9 @@ static boolean elf_hppa_unmark_useless_d
 static boolean elf_hppa_remark_useless_dynamic_symbols
   PARAMS ((struct elf_link_hash_entry *, PTR));
 
+static boolean elf_hppa_is_dynamic_loader_symbol
+  PARAMS ((const char *));
+
 static void elf_hppa_record_segment_addrs
   PARAMS ((bfd *, asection *, PTR));
 
@@ -1136,6 +1139,23 @@ elf_hppa_remark_useless_dynamic_symbols 
   return true;
 }
 
+static boolean
+elf_hppa_is_dynamic_loader_symbol (name)
+     const char * name;
+{
+  return (! strcmp (name, "__CPU_REVISION")
+	  || ! strcmp (name, "__CPU_KEYBITS_1")
+	  || ! strcmp (name, "__SYSTEM_ID_D")
+	  || ! strcmp (name, "__FPU_MODEL")
+	  || ! strcmp (name, "__FPU_REVISION")
+	  || ! strcmp (name, "__ARGC")
+	  || ! strcmp (name, "__ARGV")
+	  || ! strcmp (name, "__ENVP")
+	  || ! strcmp (name, "__TLS_SIZE_D")
+	  || ! strcmp (name, "__LOAD_INFO")
+	  || ! strcmp (name, "__systab"));
+}
+
 /* Record the lowest address for the data and text segments.  */
 static void
 elf_hppa_record_segment_addrs (abfd, section, data)
@@ -1419,11 +1439,17 @@ elf_hppa_relocate_section (output_bfd, i
 	    relocation = 0;
 	  else
 	    {
-	      if (!((*info->callbacks->undefined_symbol)
-		    (info, h->root.root.string, input_bfd,
-		     input_section, rel->r_offset, true)))
-		return false;
-	      break;
+	      /* Ignore dynamic loader defined symbols.  */
+	      if (elf_hppa_is_dynamic_loader_symbol (h->root.root.string))
+		relocation = 0;
+	      else
+		{
+		  if (!((*info->callbacks->undefined_symbol)
+			(info, h->root.root.string, input_bfd,
+			 input_section, rel->r_offset, true)))
+		    return false;
+		  break;
+		}
 	    }
 	}
 
@@ -1620,11 +1646,7 @@ elf_hppa_final_link_relocate (rel, input
 	   a local function which had its address taken.  */
 	if (dyn_h->h == NULL)
 	  {
-	    bfd_put_64 (hppa_info->dlt_sec->owner,
-			value,
-			hppa_info->dlt_sec->contents + dyn_h->dlt_offset);
-
-	    /* Now handle .opd creation if needed.  */
+	    /* Now do .opd creation if needed.  */
 	    if (r_type == R_PARISC_LTOFF_FPTR14R
 		|| r_type == R_PARISC_LTOFF_FPTR14DR
 		|| r_type == R_PARISC_LTOFF_FPTR14WR
@@ -1638,7 +1660,7 @@ elf_hppa_final_link_relocate (rel, input
 			0, 16);
 
 		/* The next word is the address of the function.  */
-		bfd_put_64 (hppa_info->opd_sec->owner, value,
+		bfd_put_64 (hppa_info->opd_sec->owner, value + addend,
 			    (hppa_info->opd_sec->contents
 			     + dyn_h->opd_offset + 16));
 
@@ -1648,7 +1670,17 @@ elf_hppa_final_link_relocate (rel, input
 		bfd_put_64 (hppa_info->opd_sec->owner, value,
 			    (hppa_info->opd_sec->contents
 			     + dyn_h->opd_offset + 24));
+
+		/* The DLT value is the address of the .opd entry.  */
+		value = (dyn_h->opd_offset
+			 + hppa_info->opd_sec->output_offset
+			 + hppa_info->opd_sec->output_section->vma);
+		addend = 0;
 	      }
+
+	    bfd_put_64 (hppa_info->dlt_sec->owner,
+			value + addend,
+			hppa_info->dlt_sec->contents + dyn_h->dlt_offset);
 	  }
 
 	/* We want the value of the DLT offset for this symbol, not
@@ -1666,7 +1698,7 @@ elf_hppa_final_link_relocate (rel, input
 	if (r_type == R_PARISC_DLTIND21L
 	    || r_type == R_PARISC_LTOFF_FPTR21L
 	    || r_type == R_PARISC_LTOFF_TP21L)
-	  value = hppa_field_adjust (value, addend, e_lrsel);
+	  value = hppa_field_adjust (value, 0, e_lsel);
 	else if (r_type == R_PARISC_DLTIND14F
 		 || r_type == R_PARISC_LTOFF_FPTR16F
 		 || r_type == R_PARISC_LTOFF_FPTR16WF
@@ -1677,9 +1709,9 @@ elf_hppa_final_link_relocate (rel, input
 		 || r_type == R_PARISC_LTOFF_TP16F
 		 || r_type == R_PARISC_LTOFF_TP16WF
 		 || r_type == R_PARISC_LTOFF_TP16DF)
-	  value = hppa_field_adjust (value, addend, e_fsel);
+	  value = hppa_field_adjust (value, 0, e_fsel);
 	else
-	  value = hppa_field_adjust (value, addend, e_rrsel);
+	  value = hppa_field_adjust (value, 0, e_rsel);
 
 	insn = elf_hppa_relocate_insn (insn, (int) value, r_type);
 	break;
@@ -1804,7 +1836,7 @@ elf_hppa_final_link_relocate (rel, input
 	    memset (hppa_info->opd_sec->contents + dyn_h->opd_offset, 0, 16);
 
 	    /* The next word is the address of the function.  */
-	    bfd_put_64 (hppa_info->opd_sec->owner, value,
+	    bfd_put_64 (hppa_info->opd_sec->owner, value + addend,
 			(hppa_info->opd_sec->contents
 			 + dyn_h->opd_offset + 16));
 
@@ -1813,6 +1845,15 @@ elf_hppa_final_link_relocate (rel, input
 		      (hppa_info->opd_sec->output_section->owner);
 	    bfd_put_64 (hppa_info->opd_sec->owner, value,
 			hppa_info->opd_sec->contents + dyn_h->opd_offset + 24);
+
+	    /* The DLT value is the address of the .opd entry.  */
+	    value = (dyn_h->opd_offset
+		     + hppa_info->opd_sec->output_offset
+		     + hppa_info->opd_sec->output_section->vma);
+
+	    bfd_put_64 (hppa_info->dlt_sec->owner,
+			value,
+			hppa_info->dlt_sec->contents + dyn_h->dlt_offset);
 	  }
 
 	/* We want the value of the DLT offset for this symbol, not
@@ -1838,7 +1879,7 @@ elf_hppa_final_link_relocate (rel, input
 	    memset (hppa_info->opd_sec->contents + dyn_h->opd_offset, 0, 16);
 
 	    /* The next word is the address of the function.  */
-	    bfd_put_64 (hppa_info->opd_sec->owner, value,
+	    bfd_put_64 (hppa_info->opd_sec->owner, value + addend,
 			(hppa_info->opd_sec->contents
 			 + dyn_h->opd_offset + 16));
 
@@ -1847,6 +1888,15 @@ elf_hppa_final_link_relocate (rel, input
 		      (hppa_info->opd_sec->output_section->owner);
 	    bfd_put_64 (hppa_info->opd_sec->owner, value,
 			hppa_info->opd_sec->contents + dyn_h->opd_offset + 24);
+
+	    /* The DLT value is the address of the .opd entry.  */
+	    value = (dyn_h->opd_offset
+		     + hppa_info->opd_sec->output_offset
+		     + hppa_info->opd_sec->output_section->vma);
+
+	    bfd_put_64 (hppa_info->dlt_sec->owner,
+			value,
+			hppa_info->dlt_sec->contents + dyn_h->dlt_offset);
 	  }
 
 	/* We want the value of the DLT offset for this symbol, not
@@ -1938,7 +1988,7 @@ elf_hppa_final_link_relocate (rel, input
 	    memset (hppa_info->opd_sec->contents + dyn_h->opd_offset, 0, 16);
 
 	    /* The next word is the address of the function.  */
-	    bfd_put_64 (hppa_info->opd_sec->owner, value,
+	    bfd_put_64 (hppa_info->opd_sec->owner, value + addend,
 			(hppa_info->opd_sec->contents
 			 + dyn_h->opd_offset + 16));
 
@@ -1955,7 +2005,7 @@ elf_hppa_final_link_relocate (rel, input
 		 + hppa_info->opd_sec->output_offset
 		 + hppa_info->opd_sec->output_section->vma);
 
-	bfd_put_64 (input_bfd, value + addend, hit_data);
+	bfd_put_64 (input_bfd, value, hit_data);
 	return bfd_reloc_ok;
       }
 
Index: bfd/elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.71
diff -u -3 -p -r1.71 elf32-hppa.c
--- bfd/elf32-hppa.c	2002/02/12 11:08:27	1.71
+++ bfd/elf32-hppa.c	2002/02/13 19:28:29
@@ -3475,21 +3475,27 @@ final_link_relocate (input_section, cont
       r_field = e_fsel;
       break;
 
-    case R_PARISC_DIR21L:
+    case R_PARISC_DLTIND21L:
     case R_PARISC_PCREL21L:
-    case R_PARISC_DPREL21L:
     case R_PARISC_PLABEL21L:
-    case R_PARISC_DLTIND21L:
+      r_field = e_lsel;
+      break;
+
+    case R_PARISC_DIR21L:
+    case R_PARISC_DPREL21L:
       r_field = e_lrsel;
       break;
 
-    case R_PARISC_DIR17R:
     case R_PARISC_PCREL17R:
-    case R_PARISC_DIR14R:
     case R_PARISC_PCREL14R:
-    case R_PARISC_DPREL14R:
     case R_PARISC_PLABEL14R:
     case R_PARISC_DLTIND14R:
+      r_field = e_rsel;
+      break;
+
+    case R_PARISC_DIR17R:
+    case R_PARISC_DIR14R:
+    case R_PARISC_DPREL14R:
       r_field = e_rrsel;
       break;
 
Index: gas/config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.93
diff -u -3 -p -r1.93 tc-hppa.c
--- gas/config/tc-hppa.c	2002/02/12 11:08:54	1.93
+++ gas/config/tc-hppa.c	2002/02/13 19:28:38
@@ -4459,7 +4459,7 @@ md_apply_fix3 (fixP, valP, seg)
       return;
     }
 
-  buf = fixP->fx_frag->fr_literal + fixP->fx_where;
+  buf = (unsigned char *) (fixP->fx_frag->fr_literal + fixP->fx_where);
   insn = bfd_get_32 (stdoutput, buf);
   fmt = bfd_hppa_insn2fmt (stdoutput, insn);
 
@@ -8398,13 +8398,8 @@ hppa_fix_adjustable (fixp)
     {
     /* Relocation types which use e_lrsel.  */
     case R_PARISC_DIR21L:
-    case R_PARISC_DLTIND21L:
     case R_PARISC_DLTREL21L:
     case R_PARISC_DPREL21L:
-    case R_PARISC_LTOFF_FPTR21L:
-    case R_PARISC_LTOFF_TP21L:
-    case R_PARISC_PCREL21L:
-    case R_PARISC_PLABEL21L:
     case R_PARISC_PLTOFF21L:
 
     /* Relocation types which use e_rrsel.  */
@@ -8412,24 +8407,15 @@ hppa_fix_adjustable (fixp)
     case R_PARISC_DIR14DR:
     case R_PARISC_DIR14WR:
     case R_PARISC_DIR17R:
-    case R_PARISC_DLTIND14R:
-    case R_PARISC_DLTIND14DR:
-    case R_PARISC_DLTIND14WR:
     case R_PARISC_DLTREL14R:
     case R_PARISC_DLTREL14DR:
     case R_PARISC_DLTREL14WR:
     case R_PARISC_DPREL14R:
     case R_PARISC_DPREL14DR:
     case R_PARISC_DPREL14WR:
-    case R_PARISC_PCREL14R:
-    case R_PARISC_PCREL17R:
-    case R_PARISC_PLABEL14R:
-    case R_PARISC_LTOFF_FPTR14R:
-    case R_PARISC_LTOFF_FPTR14DR:
-    case R_PARISC_LTOFF_FPTR14WR:
-    case R_PARISC_LTOFF_TP14R:
-    case R_PARISC_LTOFF_TP14DR:
-    case R_PARISC_LTOFF_TP14WR:
+    case R_PARISC_PLTOFF14R:
+    case R_PARISC_PLTOFF14DR:
+    case R_PARISC_PLTOFF14WR:
 
     /* Other types that we reject for reduction.  */
     case R_PARISC_GNU_VTENTRY:

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[Alan Modra]

On Tue, Feb 26, 2002 at 05:55:52PM -0500, John David Anglin wrote:
> 	* bfd/elf32-hppa.c (final_link_relocate): Revise relocation selectors
> 	as per "Processor-Specific ELF for PA_RISC, Version 1.43" document.

This change makes me a little nervous, even though I can't see anything
wrong with it.  Are you sure an asm like the following will still work?
I think it will, but I'm not sure and recall being caught out before
when I used L'/R' selectors instead of LR'/RR' in plt stubs.

 bl 0f,%0
 depi 0,31,2,%0
0:
 addil L'foo - ($PIC_pcrel$0 - 8),%0
 ldo R'foo - ($PIC_pcrel$0 - 12)(%%r1),%1

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[John David Anglin]

> This change makes me a little nervous, even though I can't see anything
> wrong with it.  Are you sure an asm like the following will still work?
> I think it will, but I'm not sure and recall being caught out before
> when I used L'/R' selectors instead of LR'/RR' in plt stubs.

I believe the issue was loading the function address and gp value in stubs.
You need LR/RR here if you want a common high value for both operations.

>  bl 0f,%0
>  depi 0,31,2,%0
> 0:
>  addil L'foo - ($PIC_pcrel$0 - 8),%0
>  ldo R'foo - ($PIC_pcrel$0 - 12)(%%r1),%1

Still works.  There is a better way to write the L and R
operators to make this clear:

PCREL21L		L(symbol - PC - 8 + addend)
PCREL14R		R(symbol - PC - 8 + addend)

These are the relocations that the above code generates.
Note that the L and R operators are applied to the sum
"symbol - PC - 8 + addend".  In your example, the sums for
the addil and ldo instructions are identical.  Thus, there
is no problem.  However, pc relative relocations are not
suitable for accessing an array or structure using a common
L value.

Compare this to the situation for the LR and RR operators.

DIR21L			LR(symbol, addend)
DIR14R			RR(symbol, addend)

These relocations are a function of both the symbol and the
addend, not just the sum.  The rounding that is done in these
relocations is applied only to the addend.  Thus, these
can't be reduced but you can access locations near symbol.

The relocations R_PARISC_PLABEL14R and R_PARISC_PLABEL21L
appear to be gnu extensions for the e_rpsel and e_lpsel selectors.
They are not documented as HP relocations.  As far as I can tell,
R_PARISC_PLABEL14R, R_PARISC_PLABEL21L and R_PARISC_PLABEL32 are
only used with an addend of 0.  Thus, it doesn't really matter
which selector type is used.  However, all DLTIND and LTOFF
relocations specified in the HP ELF spec use L and R selectors.
Thus, for consistency the R_PARISC_PLABEL21L and R_PARISC_PLABEL14R
relocations should use L and R selectors, respectively.

As I understand it, the definitions for the PLABEL relocations
used in elf32-hppa.c are:

R_PARISC_PLABEL32	fptr(symbol)
R_PARISC_PLABEL21L	L(fptr(symbol))
R_PARISC_PLABEL14R	R(fptr(symbol))

where fptr(symbol) evaluates to the official procedure descriptor for
symbol.  There is no addend for these relocations and they are only
for 32-bit code.

Hope this clarifies things.

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

Re: Special names tha ld needs to recognize for hppa64-hp-hpux11.X

[law]

In message <200202262255.g1QMtqDj004537@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > Here is a revised version of the patch to fix the '-static' linking
 > problems found under hppa64-hp-hpux11.X.  The issues fixed are:
 > 
 >   1) Dynamic loader symbols need to be ignored.
 >   2) Various problems with respect to .opd creation and the DLT entries
 >      for local symbols are fixed.  The most serious issues were that sometim
 > es
 >      we didn't create the DLT entry, and the addend was being used incorrect
 > ly.
 >   3) In reviewing the code, I noted that the selector usage for various
 >      relocations was not consistent with that specified in the HP
 >      "Processor-Specific ELF for PA-RISC, Version 1.43" document.
 >      This involved changing various relocations to L/R selectors
 >      from LR/RR selectors.  I have updated the assembler LR/RR table to
 >      reflect this change.  I believe that with this patch selector
 >      usage now pretty much conforms to that specified in the above document.
 > 
 > I have done bootstraps and checks of gcc using these tools for
 > hppa64-hp-hpux11.00 and hppa64-hp-hpux11.11.  I have also been doing
 > hppa-linux builds using tools with this patch for the past couple
 > of weeks.  Oh, I can now link programs with '-static'.
 > 
 > Please install if OK.
 > 
 > Dave
 > -- 
 > J. David Anglin                                  dave.anglin@nrc.ca
 > National Research Council of Canada              (613) 990-0752 (FAX: 952-66
 > 05)
 > 
 > 2002-02-26  John David Anglin  <dave@hiauly1.hia.nrc.ca>
 > 
 > 	* bfd/elf-hppa.h (elf_hppa_is_dynamic_loader_symbol): New function.
 > 	(elf_hppa_relocate_section): Ignore undefined dynamic loader symbols.
 > 	(elf_hppa_final_link_relocate): Correct relocations for indirect
 > 	references to local data through the DLT.  Fix .opd creation for
 > 	local symbols using R_PARISC_LTOFF_FPTR32 and R_PARISC_FPTR64
 > 	relocations.  Use e_lsel selector for R_PARISC_DLTIND21L,
 > 	R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_TP21L as per
 > 	"Processor-Specific ELF for PA_RISC, Version 1.43" document.
 > 	Similarly, use e_rsel for DLT and LTOFF 'R' relocations.
 > 	* bfd/elf32-hppa.c (final_link_relocate): Revise relocation selectors
 > 	as per "Processor-Specific ELF for PA_RISC, Version 1.43" document.
 > 	* gas/config/tc-hppa.c (md_apply_fix3): Add cast.
 > 	(hppa_fix_adjustable): Adjust list of selectors using e_lrsel and
 > 	e_rrsel.
Thanks.  I went ahead and installed your patch.

jeff

Re: i386-pc-nto-qnx patch

[Graeme Peterson]

About the ELF interpreter.  We have a different loader version in
6.1+ than in pre 6.1.  We handle this in gcc (specs) and in our
front end 'qcc' (conf files).

This is how we have done it and will probably continue to do it.
It is how we ship our tools chain, and if we need to update the
loader again, then the specs and conf files for that OS version
will reflect it.

It seems to me that it is six of one, half a dozen of the other as to
whether this gets done in gcc or binutils.  My preference is gcc,
because we need to have a QNX specific specs file anyway, this is
how we already do it, and this limits the number of QNX specific 
changes that need to be rolled in and maintained in binutils.

Who makes this decision?  There are two conflicting patch submissions,
both of which work, but not together.

Regards and thanks,
GP
 
> > 
> > "Graeme Peterson" <gp@qnx.com> writes:
> > > Here is a patch for i386-pc-nto-qnx for inclusion in
> > > GNU binutils.  Thanks to all for your help.
> > 
> > > Thanks.
> > > Looking forward to any feedback.
> > 
> > You'll need ChangeLog entries for all these changes.
> 
> Mmm.  Wondered about that.  I'll look for info on format, etc...
> 
> > 
> > Aside from the BFD changes, these changes are similar to the binutils
> > port I recently submitted.  However, I think linker configuration is
> > superior in my port.  Mine has emulparms/elf_i386_qnx.sh inheriting
> > from elf_i386.sh and elf_qnx.sh, eliminating duplicate definitions and
> > setting things up so that definitions common to all QNX ports can live 
> > in one place.
> 
> Yes, that sounds better.  It is the emulparms equivalent of what I did
> (with help from various and sundry) in the bfd backend.
> 
> > 
> > Since then, I've split it into elf_qnx60.sh and elf_qnx61.sh, as the
> > ELF interpreter is different in 6.0 and 6.1.  I think it's marginally
> > better to set the interpreter in the linker, since that allows the
> > same gcc config to target both versions of the OS.  At least this is
> > true with my gcc port.
> 
> I will have to educate myself here.  Can't comment yet...
> 
> > 
> > The config triple is i[3456]86-*-nto-qnx* in bfd, and i[3456]86-*-nto* 
> > in gas and ld.  These should probably be consistant.  I'd recommend the 
> > latter, especially if/when we have to distinguish between versions as
> > the master config.guess will return a pattern like i386-pc-nto-qnx6.10.
> 
> Yup again.  That looks better.  Consistancy is always good.  I'll make that
> change here.
> 
> Thanks, J.T.
> 
> Regards,
> GP
> 
> > 
> >         --jtc
> > 
> > -- 
> > J.T. Conklin
> > 
> 
> 
> 

Re: i386-pc-nto-qnx patch

[H . J . Lu]

On Thu, Apr 25, 2002 at 11:58:59AM -0400, Graeme Peterson wrote:
> About the ELF interpreter.  We have a different loader version in
> 6.1+ than in pre 6.1.  We handle this in gcc (specs) and in our
> front end 'qcc' (conf files).
> 
> This is how we have done it and will probably continue to do it.
> It is how we ship our tools chain, and if we need to update the
> loader again, then the specs and conf files for that OS version
> will reflect it.
> 
> It seems to me that it is six of one, half a dozen of the other as to
> whether this gets done in gcc or binutils.  My preference is gcc,
> because we need to have a QNX specific specs file anyway, this is
> how we already do it, and this limits the number of QNX specific 
> changes that need to be rolled in and maintained in binutils.
> 

Linux passes "-dynamic-linker /lib/ld.xxxx" to ld from gcc. I think
it is more flexible. We strongly discourage using ld directly for
generating DSOs and executables on Linux.


H.J.

Re: i386-pc-nto-qnx patch

[gp]

"H . J . Lu" <hjl@lucon.org> said:

> On Thu, Apr 25, 2002 at 11:58:59AM -0400, Graeme Peterson wrote:
> > About the ELF interpreter.  We have a different loader version in
> > 6.1+ than in pre 6.1.  We handle this in gcc (specs) and in our
> > front end 'qcc' (conf files).
> > 
> > This is how we have done it and will probably continue to do it.
> > It is how we ship our tools chain, and if we need to update the
> > loader again, then the specs and conf files for that OS version
> > will reflect it.
> > 
> > It seems to me that it is six of one, half a dozen of the other as to
> > whether this gets done in gcc or binutils.  My preference is gcc,
> > because we need to have a QNX specific specs file anyway, this is
> > how we already do it, and this limits the number of QNX specific 
> > changes that need to be rolled in and maintained in binutils.
> > 
> 
> Linux passes "-dynamic-linker /lib/ld.xxxx" to ld from gcc. I think
> it is more flexible. We strongly discourage using ld directly for
> generating DSOs and executables on Linux.
> 

Yup.  "--dynamic-linker /usr/lib/ldqnx.so.2" in our specs and conf files.

Thanks.
GP

> 
> H.J.
> 



-- 

Re: i386-pc-nto-qnx patch

[J.T. Conklin]

"Graeme Peterson" <gp@qnx.com> writes:
> It seems to me that it is six of one, half a dozen of the other as to
> whether this gets done in gcc or binutils.  My preference is gcc,
> because we need to have a QNX specific specs file anyway, this is
> how we already do it, and this limits the number of QNX specific 
> changes that need to be rolled in and maintained in binutils.
> 
> Who makes this decision?  There are two conflicting patch submissions,
> both of which work, but not together.

I'm not sure there is a conflict.  My gcc port supports both QNX 6.0
and 6.1, which requires the linker to know the correct interpreter.
You have separate gcc configs for the different versions of the OS, so
the same binutils config can be used.  Your gcc would presumably work
with mine, as the --dynamic-linker passed via the specs would override
the compiled in default, but my gcc port would fail.

Even though 6.0 and 6.1 are similar enough to have a common gcc config
now (assuming that ld will use the correct interpreter), I wouldn't be
surprised if some future release required separate configs.  Given that
likelyhood, I can't think of a reason to let the aesthetics of a single 
gcc config make the decision.

Additionally, it is unlikely that anyone is going to be using the
linker directly to create an executable.  Anyone who does is going to
have to know all the details of which and in what order startup files
have to be specified.  Requiring users to specify the interpreter is
not going to be a significant burden.

Having the config specify the interpreter appropriate to the specific
version of the OS does no harm, but it's benefit is slight now and is
questionable in the future (future OS releases may require separate 
gcc configs anyway).  Given this, I don't think there is a compelling
reason for me to submit this change.

There still is a conflict in the ports though, as mine still pulls out
generic QNX definitions into it's own emulparams .sh file which are 
inherited by an x86 port specific .sh file; while Graeme's has it all 
in one.  If need be, I could submit this change again if his port goes
in first.

        --jtc

-- 
J.T. Conklin

Re: i386-pc-nto-qnx patch

[Graeme Peterson]

Hey, all.

I've seen a lot of talk about merging patches, and was wondering
if anyone has had time to look at the i386-pc-nto-qnx patch I
submitted.  

Thanks.
GP

Re: i386-pc-nto-qnx patch

[Alan Modra]

On Thu, May 09, 2002 at 11:20:05AM -0400, Graeme Peterson wrote:
> I've seen a lot of talk about merging patches, and was wondering
> if anyone has had time to look at the i386-pc-nto-qnx patch I
> submitted.  

I've looked at it a couple of times, thought "why is he doing that?"
and put it aside until I could analyse your code a little deeper.

So, why is IS_CONTAINED_BY_FILEPOS necessary?  Just because
_bfd_elf_make_section_from_shdr isn't setting up lma correctly for
you?   Seems to me the right solution is some tweakery to
_bfd_elf_make_section_from_shdr.  You'll probably want this anyway
as other parts of bfd look at the section lma.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: i386-pc-nto-qnx patch

[Graeme Peterson]

Hi, Alan.  Thanks for the reply.  I will find out from the author of 
that portion and get back to you ASAP.

Cheers.
GP

> 
> On Thu, May 09, 2002 at 11:20:05AM -0400, Graeme Peterson wrote:
> > I've seen a lot of talk about merging patches, and was wondering
> > if anyone has had time to look at the i386-pc-nto-qnx patch I
> > submitted.  
> 
> I've looked at it a couple of times, thought "why is he doing that?"
> and put it aside until I could analyse your code a little deeper.
> 
> So, why is IS_CONTAINED_BY_FILEPOS necessary?  Just because
> _bfd_elf_make_section_from_shdr isn't setting up lma correctly for
> you?   Seems to me the right solution is some tweakery to
> _bfd_elf_make_section_from_shdr.  You'll probably want this anyway
> as other parts of bfd look at the section lma.
> 
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 

Re: i386-pc-nto-qnx patch

[Graeme Peterson]

Hi, Alan.

I got this from the author of the IS_CONTAINED_BY_FILEPOS stuff.
Hope it helps.  He will be looking at this a little more as well.

" If you look at the output of 'objdump -h procnto' you will see:

  procnto:     file format elf32-i386

  Sections:
  Idx Name          Size      VMA       LMA       File off  Algn
    0 ___procnto    00026bfb  080480d4  080480d4  000000d4  2**0
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    1 .text         00002024  0806ecd0  0806ecd0  00026cd0  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    2 ___c          0000954a  08070cf4  08070cf4  00028cf4  2**0
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    3 ___kercalls   00000011  0807a23e  0807a23e  0003223e  2**0
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    4 .rodata       0000080d  0807a250  0807a250  00032250  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, DATA
    5 .rodata1      00000e44  0807aa60  0807aa60  00032a60  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, DATA
    6 .data         00000f24  0807c8a4  0807c8a4  000338a4  2**2
                    CONTENTS, ALLOC, LOAD, DATA
    7 .bss          00001404  0807d7c8  0807d7c8  000347c8  2**2
                    ALLOC
    8 .segrel       000031f8  00000000  00000000  000347c8  2**0
                    CONTENTS, READONLY
    9 .segrel       000000fc  00000000  00000000  000379c0  2**0
                    CONTENTS, READONLY
   10 .note         00000038  00000000  00000000  00037abc  2**2
                    CONTENTS, READONLY

  The LMA for the .segrel sections is 0.
 
  Maybe the gnu stuff internally is setting this field from filepos or 
  calculating this but I am not sure.  I think the Gnu linker should 
  only calculate LMA for loadable sections. "

So, it seems to me that since the PT_SEGREL is not loadable, then the 
.segrel LMA is 0, so we can't use it, which is why IS_CONTAINED BY_FILEPOS
was written.  

Does that sound right?  I am on a learning curve here, and quite willing
to be corrected.  BTW, has anyone tried the patch to see if it is ok, or
if it breaks stuff?  The PT_SEGREL support in the patch works for us, and
I was curious to see if it passed other regressions.

Thanks, as always.
GP

> 
> On Thu, May 09, 2002 at 11:20:05AM -0400, Graeme Peterson wrote:
> > I've seen a lot of talk about merging patches, and was wondering
> > if anyone has had time to look at the i386-pc-nto-qnx patch I
> > submitted.  
> 
> I've looked at it a couple of times, thought "why is he doing that?"
> and put it aside until I could analyse your code a little deeper.
> 
> So, why is IS_CONTAINED_BY_FILEPOS necessary?  Just because
> _bfd_elf_make_section_from_shdr isn't setting up lma correctly for
> you?   Seems to me the right solution is some tweakery to
> _bfd_elf_make_section_from_shdr.  You'll probably want this anyway
> as other parts of bfd look at the section lma.
> 
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 

Re: i386-pc-nto-qnx patch

[Graeme Peterson]

Hi.  I haven't yet heard back specifically regarding 
IS_CONTAINED_BY_FILEPOS, but here is an overview I 
sent Nick Clifton on why we need the changes made.  
Hopefully it will help with your analysis.

I'll let you know when I get a response on the FILEPOS
stuff.

Thanks again. 

Regards,
GP

	The QNX linker issues a special class of relocations
	called segment relocations (SEGREL). The problem is
	that GNU BFD removes these sections.  For example,
	if you strip the QNX6 kernel (procnto) or objcopy it,
	it is no longer usable, because the linker used in
	building boot images (ldrel) needs segment relocations.
	
	We need to preserve these sections and segments with
	proper offset and size.
	
	The function _bfd_elf_copy_private_section_data() calls
	copy_private_bfd_data() only for ALLOCATED sections.
	copy_private_bfd_data() creates internal structures
	for segments composed of sections (mapping output sections
	to segments) but only for ALLOCATED sections. For these
	reasons I redesigned these functions.  This function
	worked for PT_LOAD and PT_NOTE segments, and for non
	PT_LOAD segments containing at least one allocated
	section.  The PT_SEGREL has no such sections.


> 
> Hi, Alan.  Thanks for the reply.  I will find out from the author of 
> that portion and get back to you ASAP.
> 
> Cheers.
> GP
> 
> > 
> > On Thu, May 09, 2002 at 11:20:05AM -0400, Graeme Peterson wrote:
> > > I've seen a lot of talk about merging patches, and was wondering
> > > if anyone has had time to look at the i386-pc-nto-qnx patch I
> > > submitted.  
> > 
> > I've looked at it a couple of times, thought "why is he doing that?"
> > and put it aside until I could analyse your code a little deeper.
> > 
> > So, why is IS_CONTAINED_BY_FILEPOS necessary?  Just because
> > _bfd_elf_make_section_from_shdr isn't setting up lma correctly for
> > you?   Seems to me the right solution is some tweakery to
> > _bfd_elf_make_section_from_shdr.  You'll probably want this anyway
> > as other parts of bfd look at the section lma.
> > 
> > -- 
> > Alan Modra
> > IBM OzLabs - Linux Technology Centre
> > 
> 
> 

Re: Miscellaneous fixes for testsuite failures on hppa64-hp-hpux11.00

[John David Anglin]

> There is one additional failure with gcc which I am currently investigating.

The test ld-scripts/crossref.exp fails when ld is compiled with gcc but
not the HP ansi compiler.  Here is the test output with the HP compiler:

Running /xxx/gnu/binutils-2.12.90/src/ld/testsuite/ld-scripts/crossref.exp ...
/opt/gnu64/bin/gcc -L/xxx/gnu/binutils-2.12.90/objdir64/ld -B/xxx/gnu/binutils-2
.12.90/objdir64/ld/tmpdir/gas/ -I/xxx/gnu/binutils-2.12.90/src/ld/testsuite/ld-s
cripts   -c /xxx/gnu/binutils-2.12.90/src/ld/testsuite/ld-scripts/cross1.c -o tm
pdir/cross1.o
/opt/gnu64/bin/gcc -L/xxx/gnu/binutils-2.12.90/objdir64/ld -B/xxx/gnu/binutils-2
.12.90/objdir64/ld/tmpdir/gas/ -I/xxx/gnu/binutils-2.12.90/src/ld/testsuite/ld-s
cripts   -c /xxx/gnu/binutils-2.12.90/src/ld/testsuite/ld-scripts/cross2.c -o tm
pdir/cross2.o
/xxx/gnu/binutils-2.12.90/objdir64/ld/ld-new  -o tmpdir/cross1 -T /xxx/gnu/binut
ils-2.12.90/src/ld/testsuite/ld-scripts/cross1.t tmpdir/cross1.o tmpdir/cross2.o
/xxx/gnu/binutils-2.12.90/objdir64/ld/ld-new: BFD 2.12.90 20020606 assertion fai
l ../../src/bfd/elflink.h:5735
/xxx/gnu/binutils-2.12.90/objdir64/ld/ld-new: BFD 2.12.90 20020606 assertion fai
l ../../src/bfd/elflink.h:5735
/xxx/gnu/binutils-2.12.90/objdir64/ld/ld-new: BFD 2.12.90 20020606 assertion fai
l ../../src/bfd/elflink.h:5735
tmpdir/cross1.o: In function `func':
tmpdir/cross1.o(.text+0x1c): prohibited cross reference from .text to `foo' in .
data
PASS: NOCROSSREFS 1

The code is

              o = bfd_get_section_by_name (abfd, name);
	      BFD_ASSERT (o != NULL);
	      dyn.d_un.d_ptr = o->vma;

With gcc, the NULL pointer causes a segmentation fault but with the HP
compiler this appears not to be the default behavior.  The first assertion
failure is caused by trying to get the section pointer for the ".hash"
section.  In the output abfd, there are 7 sections but only

1	.opd
2	.text
3	.data
7	.dynamic

have non-null section pointers.

I had thought that this was a gcc problem but this appears not to be
the case.

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

Re: Miscellaneous fixes for testsuite failures on hppa64-hp-hpux11.00

[law]

 In message <200206060605.g5665NmJ021745@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > With gcc, the NULL pointer causes a segmentation fault but with the HP
 > compiler this appears not to be the default behavior.  The first assertion
 > failure is caused by trying to get the section pointer for the ".hash"
 > section.  In the output abfd, there are 7 sections but only
[ ... ]
Yes, by default, GCC will arrange to pass the right magic flags to ld to
get segfaults on a null pointer dereference.  HP's compiler's by default
allow the null pointer dereference.

Jeff

Re: PATCH: Re: hppa64-hp-hpux11.00: invalid string offset for section .dynstr

[John David Anglin]

> 2002-06-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	* elf64-hppa.c (clobber_millicode_symbols): New function.
> 	(allocate_global_data_dlt):  Don't add millicode symbols to dynamic
> 	symbol table.
> 	(allocate_global_data_opd, allocate_dynrel_entries): Likewise.
> 	(elf64_hppa_size_dynamic_sections): Traverse hash table to keep
> 	millicode symbols out of dynamic symbol table.
> 	(elf64_hppa_finish_dynamic_symbol): Remove code to keep millicode
> 	symbols out of dynamic symbol table.

In thinking more about the above patch, I realized that it's possible
to save one traversal of the hash table by combining the marking of
exported functions and the millicode symbol processing.

Tested with binutils and mainline gcc builds on hppa64-hp-hpux11.00.
No regressions were observed.

Please install if ok.

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

2002-06-23  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* elf64-hppa.c (elf64_hppa_mark_milli_and_exported_functions): New
	function.
	(allocate_global_data_dlt):  Don't add millicode symbols to dynamic
	symbol table.
	(allocate_global_data_opd, allocate_dynrel_entries): Likewise.
	(elf64_hppa_size_dynamic_sections): Revise to use
	elf64_hppa_mark_milli_and_exported_functions.
	(elf64_hppa_finish_dynamic_symbol): Remove code to keep millicode
	symbols out of dynamic symbol table.

Index: elf64-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-hppa.c,v
retrieving revision 1.23
diff -u -3 -p -r1.23 elf64-hppa.c
--- elf64-hppa.c	16 Jun 2002 15:32:08 -0000	1.23
+++ elf64-hppa.c	23 Jun 2002 04:06:36 -0000
@@ -195,6 +195,9 @@ static boolean elf64_hppa_create_dynamic
 static boolean elf64_hppa_adjust_dynamic_symbol
   PARAMS ((struct bfd_link_info *, struct elf_link_hash_entry *));
 
+static boolean elf64_hppa_mark_milli_and_exported_functions
+  PARAMS ((struct elf_link_hash_entry *, PTR));
+
 static boolean elf64_hppa_size_dynamic_sections
   PARAMS ((bfd *, struct bfd_link_info *));
 
@@ -1073,7 +1076,7 @@ allocate_global_data_dlt (dyn_h, data)
 	     table since we might need to create a dynamic relocation
 	     against it.  */
 	  if (! h
-	      || (h && h->dynindx == -1))
+	      || (h->dynindx == -1 && h->type != STT_PARISC_MILLI))
 	    {
 	      bfd *owner;
 	      owner = (h ? h->root.u.def.section->owner : dyn_h->owner);
@@ -1168,7 +1171,7 @@ allocate_global_data_opd (dyn_h, data)
 	 we have to create an opd descriptor.  */
       else if (x->info->shared
 	       || h == NULL
-	       || h->dynindx == -1
+	       || (h->dynindx == -1 && h->type != STT_PARISC_MILLI)
 	       || (h->root.type == bfd_link_hash_defined
 		   || h->root.type == bfd_link_hash_defweak))
 	{
@@ -1542,7 +1545,8 @@ allocate_dynrel_entries (dyn_h, data)
       /* Make sure this symbol gets into the dynamic symbol table if it is
 	 not already recorded.  ?!? This should not be in the loop since
 	 the symbol need only be added once.  */
-      if (dyn_h->h == 0 || dyn_h->h->dynindx == -1)
+      if (dyn_h->h == 0
+	  || (dyn_h->h->dynindx == -1 && dyn_h->h->type != STT_PARISC_MILLI))
 	if (!_bfd_elf64_link_record_local_dynamic_symbol
 	    (x->info, rent->sec->owner, dyn_h->sym_indx))
 	  return false;
@@ -1610,6 +1614,36 @@ elf64_hppa_adjust_dynamic_symbol (info, 
   return true;
 }
 
+/* This function is called via elf_link_hash_traverse to mark millicode
+   symbols with a dynindx of -1 and to remove the string table reference
+   from the dynamic symbol table.  If the symbol is not a millicode symbol,
+   elf64_hppa_mark_exported_functions is called.  */
+
+static boolean
+elf64_hppa_mark_milli_and_exported_functions (h, data)
+     struct elf_link_hash_entry *h;
+     PTR data;
+{
+  struct bfd_link_info *info = (struct bfd_link_info *)data;
+  struct elf_link_hash_entry *elf = h;
+
+  if (elf->root.type == bfd_link_hash_warning)
+    elf = (struct elf_link_hash_entry *) elf->root.u.i.link;
+
+  if (elf->type == STT_PARISC_MILLI)
+    {
+      if (elf->dynindx != -1)
+	{
+	  elf->dynindx = -1;
+	  _bfd_elf_strtab_delref (elf_hash_table (info)->dynstr,
+				  elf->dynstr_index);
+	}
+      return true;
+    }
+
+  return elf64_hppa_mark_exported_functions (h, data);
+}
+
 /* Set the final sizes of the dynamic sections and allocate memory for
    the contents of our special sections.  */
 
@@ -1631,6 +1665,19 @@ elf64_hppa_size_dynamic_sections (output
   dynobj = elf_hash_table (info)->dynobj;
   BFD_ASSERT (dynobj != NULL);
 
+  /* Mark each function this program exports so that we will allocate
+     space in the .opd section for each function's FPTR.  If we are
+     creating dynamic sections, change the dynamic index of millicode
+     symbols to -1 and remove them from the string table for .dynstr.
+
+     We have to traverse the main linker hash table since we have to
+     find functions which may not have been mentioned in any relocs.  */
+  elf_link_hash_traverse (elf_hash_table (info),
+			  (elf_hash_table (info)->dynamic_sections_created
+			   ? elf64_hppa_mark_milli_and_exported_functions
+			   : elf64_hppa_mark_exported_functions),
+			  info);
+
   if (elf_hash_table (info)->dynamic_sections_created)
     {
       /* Set the contents of the .interp section to the interpreter.  */
@@ -1675,15 +1722,6 @@ elf64_hppa_size_dynamic_sections (output
       hppa_info->stub_sec->_raw_size = data.ofs;
     }
 
-  /* Mark each function this program exports so that we will allocate
-     space in the .opd section for each function's FPTR.
-
-     We have to traverse the main linker hash table since we have to
-     find functions which may not have been mentioned in any relocs.  */
-  elf_link_hash_traverse (elf_hash_table (info),
-			  elf64_hppa_mark_exported_functions,
-			  info);
-
   /* Allocate space for entries in the .opd section.  */
   if (elf64_hppa_hash_table (info)->opd_sec)
     {
@@ -2098,11 +2136,6 @@ elf64_hppa_finish_dynamic_symbol (output
       bfd_put_32 (stub->owner, (bfd_vma) insn,
 		  stub->contents + dyn_h->stub_offset + 8);
     }
-
-  /* Millicode symbols should not be put in the dynamic
-     symbol table under any circumstances.  */
-  if (ELF_ST_TYPE (sym->st_info) == STT_PARISC_MILLI)
-    h->dynindx = -1;
 
   return true;
 }

Re: PATCH: Re: hppa64-hp-hpux11.00: invalid string offset for section .dynstr

[Alan Modra]

On Sun, Jun 23, 2002 at 01:42:23AM -0400, John David Anglin wrote:
> 	* elf64-hppa.c (elf64_hppa_mark_milli_and_exported_functions): New
> 	function.
> 	(allocate_global_data_dlt):  Don't add millicode symbols to dynamic
> 	symbol table.
> 	(allocate_global_data_opd, allocate_dynrel_entries): Likewise.
> 	(elf64_hppa_size_dynamic_sections): Revise to use
> 	elf64_hppa_mark_milli_and_exported_functions.
> 	(elf64_hppa_finish_dynamic_symbol): Remove code to keep millicode
> 	symbols out of dynamic symbol table.

Committed.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: hpux64-hp-hpux11.00: .rela.opd problems

[John David Anglin]

> 2002-06-26  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	* elf64-hppa.c (elf64_hppa_reloc_type_class): New function.
> 	(elf64_hppa_finish_dynamic_sections): Check other_rel_sec, dlt_rel_sec
> 	and opd_rel_sec in order for starting rela section.  Check _raw_size.
> 	(elf_backend_reloc_type_class): Define.
> 	* emulparams/hppa64linux.sh (OTHER_GOT_RELOC_SECTIONS): Add rela.opd
> 	section.  Add ${RELOCATING-0}.

Ross's problems are resolved at least for now.  Would one of the maintainers
review the above <http://sources.redhat.com/ml/binutils/2002-06/msg00735.html>
and install if OK?  It ensures that we search correctly for the beginning
of the rela sections in computing the value for DT_RELA.  It also classifies
relocs which may improve how they are sorted.

The patch has been tested with several binutils builds under hppa64-hp-hpux11*
and a gcc build under hppa64-hp-hpux11.11.

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

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> > 2002-07-10  Alan Modra  <amodra@bigpond.net.au>
> > 
> > 	* merge.c (_bfd_merge_section): Remove redundant output_section check.
> > 	Formatting.
> > 	(_bfd_merge_sections): Don't set SEC_EXCLUDE on unused sections.
> 
> bash-2.05a$ ./ld --version
> GNU ld version 2.12.90 20020716
> 
> As shown in the original gdb output, the output section is *ABS* which
> doesn't seem resonable for the symbol which is a weak function.  I

Looking at the history of the above, I see that the bug being fixed
had sym_sec->output_section set to bfd_abs_section.  The code in this
case was also being compiled with "-ffunction-sections" and we seem to
have the same problem, but on hppa64.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Tue, Jul 16, 2002 at 08:34:40PM -0400, John David Anglin wrote:
> Looking at the history of the above, I see that the bug being fixed
> had sym_sec->output_section set to bfd_abs_section.  The code in this
> case was also being compiled with "-ffunction-sections" and we seem to
> have the same problem, but on hppa64.

Looking at your original email again.. :)  I see that what's happening
is that you're trying to output a dynamic symbol from a removed
linkonce section.  You need to find why ld is trying to do that, or in
fact why ld is outputting dynamic symbols for debugging sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Tue, Jul 16, 2002 at 08:34:40PM -0400, John David Anglin wrote:
> > Looking at the history of the above, I see that the bug being fixed
> > had sym_sec->output_section set to bfd_abs_section.  The code in this
> > case was also being compiled with "-ffunction-sections" and we seem to
> > have the same problem, but on hppa64.
> 
> Looking at your original email again.. :)  I see that what's happening
> is that you're trying to output a dynamic symbol from a removed
> linkonce section.  You need to find why ld is trying to do that, or in
> fact why ld is outputting dynamic symbols for debugging sections.

This could be the definition for ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:

/* Handle special EH pointer encodings.  Absolute, pc-relative, and
   indirect are handled automatically.  Since pc-relative encoding is
   not possible on the PA and we don't have the infrastructure for
   data relative encoding, we use aligned plabels for global function
   pointers.  */
#define ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX(FILE, ENCODING, SIZE, ADDR, DONE) \
  do {                                                                  \
    if (((ENCODING) & 0x0F) == DW_EH_PE_aligned)                        \
      {                                                                 \
	fputs (integer_asm_op (SIZE, FALSE), FILE);                     \
	fputs ("P%", FILE);                                             \
	assemble_name (FILE, XSTR (ADDR, 0));                           \
	goto DONE;                                                      \
      }                                                                 \
    } while (0)

However, I didn't think that this is the problem since this still appears
to work under hppa-linux.  As far as I can tell, the only uses of the
above is to obtain the address of the personality function.  This also
occurs in a section which is loaded.

From the debugging I did, the symbols appear to be symbols for
weak functions.

I have confirmed that the problem is somehow related to the generation
of dwarf2 eh information.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Tue, Jul 16, 2002 at 10:30:57PM -0400, John David Anglin wrote:
> I have confirmed that the problem is somehow related to the generation
> of dwarf2 eh information.

Yes, I suspect you're emitting dynamic relocs in debug sections.
If so, that needs to be stopped.  It's pointless because ld.so
won't relocate debug sections for you, and causes exactly the sort
of problems you're seeing.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> Looking at your original email again.. :)  I see that what's happening
> is that you're trying to output a dynamic symbol from a removed
> linkonce section.  You need to find why ld is trying to do that, or in
> fact why ld is outputting dynamic symbols for debugging sections.

Comparing the object files for string-inst.o with and without eh
frame info, the main difference in section information appears to
be that the file with eh frame info has a .debug_frame section
that the other doesn't have.  It has relocations like

RELOCATION RECORDS FOR [.debug_frame]:
OFFSET           TYPE              VALUE
0000000000000014 R_PARISC_SECREL32  .debug_frame
0000000000000018 R_PARISC_DIR64    .gnu.linkonce.t._ZNKSs7_M_dataEv
000000000000003c R_PARISC_SECREL32  .debug_frame
0000000000000040 R_PARISC_DIR64    .gnu.linkonce.t._ZNSs7_M_dataEPc
...

The hppa-linux 32-bit relocations are

RELOCATION RECORDS FOR [.debug_frame]:
OFFSET   TYPE              VALUE
00000014 R_PARISC_DIR32    .debug_frame
00000018 R_PARISC_DIR32    .gnu.linkonce.t._ZNKSs7_M_dataEv
00000024 R_PARISC_DIR32    .debug_frame
00000028 R_PARISC_DIR32    .gnu.linkonce.t._ZNSs7_M_dataEPc
...

I would guess that's the R_PARISC_DIR64 relocs that are the problem
but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.

Because elf32_hppa_check_relocs has this code

      if (need_entry & NEED_DYNREL)
	{
.
.
	  if (...
	       && (sec->flags & SEC_ALLOC) != 0

and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
debugging sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
> 
> Because elf32_hppa_check_relocs has this code
> 
>       if (need_entry & NEED_DYNREL)
> 	{
> .
> .
> 	  if (...
> 	       && (sec->flags & SEC_ALLOC) != 0
> 
> and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
> debugging sections.

Hmmm, there seems to be a similar check in elf64-hppa.c

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

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
> 
> Because elf32_hppa_check_relocs has this code
> 
>       if (need_entry & NEED_DYNREL)
> 	{
> .
> .
> 	  if (...
> 	       && (sec->flags & SEC_ALLOC) != 0
> 
> and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
> debugging sections.

I don't think this is the problem.  As far as I can tell, we are
not emitting dynamic relocs for the debugging sections.

If you look back at the original report, you will see that the
".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section has its output_section
set to the bfd_abs_section.  It has SEC_ALLOC set in its flags
and SEC_EXCLUDE is not set.  It has a nonzero size.  Thus, the
only apparent reason that the output_section for this section
is set to the bfd_abs_section is that there are multiple copies
of this weak function/section.  Looking at the .o source files,
there appear to be four input objects containing this weak
function.

There are a couple of possibilities for the symbol reference
that causes the problem.  I know that the reloc is local,
from the .data section, from io-inst.o.  The SEC_ALLOC is
set in the flags of the .data section when the symbol is put
onto the dynlocal list.

We have the following assembly code for for _ZTv0_n24_NSdD1Ev in io-inst.s:

        .IMPORT _ZTv0_n24_NSdD1Ev,ENTRY
	.section        .gnu.linkonce.t._ZTv0_n24_NSdD1Ev,"ax",@progbits
	.align 8
	.weak   _ZTv0_n24_NSdD1Ev
	.EXPORT _ZTv0_n24_NSdD1Ev,ENTRY
L$FB1521
	.loc 40 64 0
_ZTv0_n24_NSdD1Ev
	.PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
L$CFI0122
	...

The symbol that causes the problem comes from io-inst.o.  io-inst.o
is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that
causes the seg fault.  The most likely symbol is a reference to
L$FB1521 in the .data section:

L$SFDE0073
        .word   L$EFDE0073-L$ASFDE0073
L$ASFDE0073
	.word   L$ASFDE0073-L$frame0001
	.dword  L$FB1521
	.dword  L$FE1521-L$FB1521
	...

This is code is not present without eh information, so we have the
link with enabling eh frame information.  The above is also consistent
with the DIR64 reloc.

So, what do we do?  We have have a reference in the data section
to a local label in a function that has been deleted.  On hppa-linux,
the above data is in .eh_frame.  Is it somehow special?

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Wed, Jul 17, 2002 at 11:20:02PM -0400, John David Anglin wrote:
> The symbol that causes the problem comes from io-inst.o.  io-inst.o
> is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that
> causes the seg fault.  The most likely symbol is a reference to
> L$FB1521 in the .data section:
> 
> L$SFDE0073
>         .word   L$EFDE0073-L$ASFDE0073
> L$ASFDE0073
> 	.word   L$ASFDE0073-L$frame0001
> 	.dword  L$FB1521
> 	.dword  L$FE1521-L$FB1521
> 	...
> 
> This is code is not present without eh information, so we have the
> link with enabling eh frame information.  The above is also consistent
> with the DIR64 reloc.
> 
> So, what do we do?  We have have a reference in the data section
> to a local label in a function that has been deleted.  On hppa-linux,
> the above data is in .eh_frame.  Is it somehow special?

OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
.eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> > So, what do we do?  We have have a reference in the data section
> > to a local label in a function that has been deleted.  On hppa-linux,
> > the above data is in .eh_frame.  Is it somehow special?
> 
> OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.

I put the eh data into .eh_frame.  However, I still get a seg fault
at the same spot although the symbol and section have changed.  It
looks as if the code figured out that the reloc symbol was deleted
but still the fault.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Thu, Jul 18, 2002 at 02:06:50AM -0400, John David Anglin wrote:
> > > So, what do we do?  We have have a reference in the data section
> > > to a local label in a function that has been deleted.  On hppa-linux,
> > > the above data is in .eh_frame.  Is it somehow special?
> > 
> > OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> > .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.
> 
> I put the eh data into .eh_frame.  However, I still get a seg fault
> at the same spot although the symbol and section have changed.  It
> looks as if the code figured out that the reloc symbol was deleted
> but still the fault.

Take a look at what's happening at elf64-hppa.c:1514 under gdb.
I suspect you have forced-local syms being added as local dynamic
syms.  Bad.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 2342 bytes --]

> On Thu, Jul 18, 2002 at 02:06:50AM -0400, John David Anglin wrote:
> > > > So, what do we do?  We have have a reference in the data section
> > > > to a local label in a function that has been deleted.  On hppa-linux,
> > > > the above data is in .eh_frame.  Is it somehow special?
> > > 
> > > OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> > > .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.
> > 
> > I put the eh data into .eh_frame.  However, I still get a seg fault
> > at the same spot although the symbol and section have changed.  It
> > looks as if the code figured out that the reloc symbol was deleted
> > but still the fault.
> 
> Take a look at what's happening at elf64-hppa.c:1514 under gdb.
> I suspect you have forced-local syms being added as local dynamic
> syms.  Bad.

I believe that only dynamic local syms are being added.  reloc_entries
are added to list by count_dyn_reloc.  This is only called when need_entry
has NEED_DYNREL, and sec->flags & SEC_ALLOC.  However, this is the path
by which the local dyn symbols are being added.  This must be something
wrong with the removal process for local dyn symbols.

I hacked elflink.h to skip discarded sections.  However, now ld
seg faults linking apps:

/xxx/gnu/gcc-3.2/objdir/gcc/libgcc.a(__main.o): In function `__do_global_dtors':
/xxx/gnu/gcc-3.2/objdir/gcc/../../gcc/gcc/libgcc2.c:1899: undefined reference to `__EH_FRAME_BEGIN__'

Program received signal SIGSEGV, Segmentation fault.
0x4000000000063164 in elf64_hppa_finalize_dlt (dyn_h=???, data=???)
    at ../../src/bfd/elf64-hppa.c:2271
2271                value += h->root.u.def.section->output_section->vma;
(gdb) p h->root
$3 = {root = {next = 0x8000000000154490,
    string = 0x800000000017e4be "__EH_FRAME_BEGIN__", hash = 60347007},
  type = bfd_link_hash_undefined, next = 0x80000000000eea30, u = {undef = {
      abfd = 0x8000000000091ad0}, def = {value = 9223372036855372496,
      section = 0x4000000000096420}, i = {link = 0x8000000000091ad0,
      warning = 0x4000000000096420 "òs\020!\n\223\n3òs\020c\n³\n36u"}, c = {
      size = 9223372036855372496, p = 0x4000000000096420}}}
	
Too many bugs.

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

Re: QNX binutils targets

[Graeme Peterson]

I also noticed that not all of the qnx bfd's are in targets.c:

 $ grep qnx targets.c
 targets.c:extern const bfd_target bfd_elf32_bigarmqnx_vec;
 targets.c:extern const bfd_target bfd_elf32_i386qnx_vec;
 targets.c:extern const bfd_target bfd_elf32_littlearmqnx_vec;
 targets.c:extern const bfd_target bfd_elf32_powerpcleqnx_vec;
 targets.c:extern const bfd_target bfd_elf32_powerpcqnx_vec;
 targets.c:extern const bfd_target bfd_elf32_shlqnx_vec;
 targets.c:extern const bfd_target bfd_elf32_shqnx_vec;
 targets.c:      &bfd_elf32_i386qnx_vec,
 targets.c:      &bfd_elf32_powerpcleqnx_vec,
 targets.c:      &bfd_elf32_powerpcqnx_vec,

Shouldn't there also be:

 targets.c:      &bfd_elf32_bigarmqnx_vec,
 targets.c:      &bfd_elf32_littlearmqnx_vec,
 targets.c:      &bfd_elf32_shlqnx_vec,
 targets.c:      &bfd_elf32_shqnx_vec,

Looks like an ommission somewhere along the line.

Thanks.
GP

> 
> Hi, Alan.
> 
> I was away and missed your mail.
> 
> Thanks for fixing this, it is fine with me (he said too late anyway).
> 
> :-)
> 
> Cheers.
> GP
> 
> > 
> > The QNX targets were reusing bfd target names.  Not good if you're
> > building a multiple-target bfd lib and would like to specify a
> > QNX target.  So I've chosen some new names, in line with other targets
> > that have a wrinkle on a more generic target.  If the names don't suit,
> > speak up!
> > 
> > bfd/ChangeLog
> > 	* elf32-i386qnx.c (TARGET_LITTLE_NAME): Define.
> > 	* elf32-ppcqnx.c (TARGET_LITTLE_NAME, TARGET_BIG_NAME): Define.
> > 	* elf32-shqnx.c (TARGET_LITTLE_NAME, TARGET_BIG_NAME): Define.
> > 	* elfarmqnx-nabi.c (TARGET_LITTLE_NAME, TARGET_BIG_NAME): Define.
> > 
> > Index: bfd/elf32-i386qnx.c
> > ===================================================================
> > RCS file: /cvs/src/src/bfd/elf32-i386qnx.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 elf32-i386qnx.c
> > --- bfd/elf32-i386qnx.c	9 Aug 2002 15:38:22 -0000	1.3
> > +++ bfd/elf32-i386qnx.c	15 Oct 2002 07:23:52 -0000
> > @@ -24,7 +24,8 @@
> >  #include "elf32-qnx.h"
> >  
> >  #undef  TARGET_LITTLE_SYM
> > -#define TARGET_LITTLE_SYM		    bfd_elf32_i386qnx_vec
> > +#define TARGET_LITTLE_SYM		bfd_elf32_i386qnx_vec
> > +#undef  TARGET_LITTLE_NAME
> > +#define TARGET_LITTLE_NAME		"elf32-i386-nto"
> >  
> >  #include "elf32-target.h"
> > -
> > Index: bfd/elf32-ppcqnx.c
> > ===================================================================
> > RCS file: /cvs/src/src/bfd/elf32-ppcqnx.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 elf32-ppcqnx.c
> > --- bfd/elf32-ppcqnx.c	9 Aug 2002 15:39:19 -0000	1.1
> > +++ bfd/elf32-ppcqnx.c	15 Oct 2002 07:23:52 -0000
> > @@ -25,8 +25,11 @@
> >  
> >  #undef  TARGET_LITTLE_SYM 
> >  #define TARGET_LITTLE_SYM       bfd_elf32_powerpcleqnx_vec
> > +#undef  TARGET_LITTLE_NAME
> > +#define TARGET_LITTLE_NAME	"elf32-powerpcle-nto"
> >  #undef  TARGET_BIG_SYM
> >  #define TARGET_BIG_SYM          bfd_elf32_powerpcqnx_vec
> > +#undef  TARGET_BIG_NAME
> > +#define TARGET_BIG_NAME		"elf32-powerpc-nto"
> >  
> >  #include "elf32-target.h"
> > -
> > Index: bfd/elf32-shqnx.c
> > ===================================================================
> > RCS file: /cvs/src/src/bfd/elf32-shqnx.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 elf32-shqnx.c
> > --- bfd/elf32-shqnx.c	22 Aug 2002 17:27:19 -0000	1.1
> > +++ bfd/elf32-shqnx.c	15 Oct 2002 07:23:52 -0000
> > @@ -24,8 +24,11 @@
> >  
> >  #undef  TARGET_LITTLE_SYM 
> >  #define TARGET_LITTLE_SYM       bfd_elf32_shlqnx_vec
> > +#undef  TARGET_LITTLE_NAME
> > +#define TARGET_LITTLE_NAME	"elf32-shl-nto"
> >  #undef  TARGET_BIG_SYM
> >  #define TARGET_BIG_SYM          bfd_elf32_shqnx_vec
> > +#undef  TARGET_BIG_NAME
> > +#define TARGET_BIG_NAME		"elf32-sh-nto"
> >  
> >  #include "elf32-target.h"
> > -
> > Index: bfd/elfarmqnx-nabi.c
> > ===================================================================
> > RCS file: /cvs/src/src/bfd/elfarmqnx-nabi.c,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 elfarmqnx-nabi.c
> > --- bfd/elfarmqnx-nabi.c	9 Aug 2002 15:38:22 -0000	1.2
> > +++ bfd/elfarmqnx-nabi.c	15 Oct 2002 07:23:52 -0000
> > @@ -24,8 +24,12 @@
> >  
> >  #undef  TARGET_LITTLE_SYM 
> >  #define TARGET_LITTLE_SYM       bfd_elf32_littlearmqnx_vec
> > +#undef  TARGET_LITTLE_NAME
> > +#define TARGET_LITTLE_NAME	"elf32-littlearm-nto"
> >  #undef  TARGET_BIG_SYM
> >  #define TARGET_BIG_SYM          bfd_elf32_bigarmqnx_vec
> > +#undef  TARGET_BIG_NAME
> > +#define TARGET_BIG_NAME		"elf32-bigarm-nto"
> >  
> >  /* QNX Neutrino for ARM has a max pagesize of 0x1000.  */
> >  #undef  ELF_MAXPAGESIZE
> > 
> > -- 
> > Alan Modra
> > IBM OzLabs - Linux Technology Centre
> > 
> 
> 

Re: K&R patch for binutils bfd directory

[John David Anglin]

> Wasn't a BFD things-to-do-today thwack ``true'' and ``false''? Someone is definitly ment to be removing them from bfd.h.

I have no objection.  However, the function declaration needs to be consistent
with the return value when it is an enum to avoid warnings.  It doesn't make
a lot of sense to cast a bunch of zeros and ones to boolean.

Gcc uses TRUE and FALSE, and the type _Bool.  They are based on stdbool.h
when available.  However, the comment says they must be defined after all
inclusion of system headers.

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

Re: Patch to config.guess (2002-07-03) to detect 64bit HPUX compiler

[John David Anglin]

> I applied the patch to config.guess in gcc-3.3.  I had to apply it
> manually because of minor formatting differences.  It didn't work
> correctly.  The following appeared in the gcc build log.  I was
> using a 64-bit gcc as the build compiler.
> 
> ../gcc/config.guess[631]: tmpdir=${TMPDIR-/tmp}/config-guess-$$:  not found.
> ../gcc/config.guess[632]: -E:  not found.
> Configuring for a hppa64-hp-hpux11.11 host.
> ...

We need to eval $set_cc_for_build.  I am doing a gcc bootstrap with
the patch below.  I have verified that it correctly selects hppa64
when using gcc (64-bit version selected using $PATH) and the HP
bundled compiler selected with CC="cc +DA2.0W".

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

Index: config.guess
===================================================================
RCS file: /cvsroot/gcc/gcc/config.guess,v
retrieving revision 1.53
diff -u -3 -p -r1.53 config.guess
--- config.guess	20 Aug 2002 21:53:23 -0000	1.53
+++ config.guess	3 Dec 2002 16:19:35 -0000
@@ -621,10 +621,21 @@ EOF
               }
 EOF
 		    (CCOPTS= $CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null) && HP_ARCH=`$dummy`
-		    if test -z "$HP_ARCH"; then HP_ARCH=hppa; fi
+		    test -z "$HP_ARCH" && HP_ARCH=hppa
 		    rm -f $dummy.c $dummy && rmdir $tmpdir
 		fi ;;
 	esac
+	if [ ${HP_ARCH} = "hppa2.0w" ]
+	then
+	    # avoid double evaluation of $set_cc_for_build
+	    test -n "$CC_FOR_BUILD" || eval $set_cc_for_build
+	    if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__
+	    then
+		HP_ARCH="hppa2.0w"
+	    else
+		HP_ARCH="hppa64"
+	    fi
+	fi
 	echo ${HP_ARCH}-hp-hpux${HPUX_REV}
 	exit 0 ;;
     ia64:HP-UX:*:*)

Re: Patch to config.guess (2002-07-03) to detect 64bit HPUX compiler

[John David Anglin]

> We need to eval $set_cc_for_build.  I am doing a gcc bootstrap with
> the patch below.  I have verified that it correctly selects hppa64
> when using gcc (64-bit version selected using $PATH) and the HP
> bundled compiler selected with CC="cc +DA2.0W".

There was a further problem...  I directed the output of the
__LP64__ check to /dev/null.  I guess the "-q" was necessary.

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

Index: config.guess
===================================================================
RCS file: /cvsroot/gcc/gcc/config.guess,v
retrieving revision 1.53
diff -u -3 -p -r1.53 config.guess
--- config.guess	20 Aug 2002 21:53:23 -0000	1.53
+++ config.guess	3 Dec 2002 22:29:52 -0000
@@ -621,10 +621,21 @@ EOF
               }
 EOF
 		    (CCOPTS= $CC_FOR_BUILD $dummy.c -o $dummy 2>/dev/null) && HP_ARCH=`$dummy`
-		    if test -z "$HP_ARCH"; then HP_ARCH=hppa; fi
+		    test -z "$HP_ARCH" && HP_ARCH=hppa
 		    rm -f $dummy.c $dummy && rmdir $tmpdir
 		fi ;;
 	esac
+	if [ ${HP_ARCH} = "hppa2.0w" ]
+	then
+	    # avoid double evaluation of $set_cc_for_build
+	    test -n "$CC_FOR_BUILD" || eval $set_cc_for_build
+	    if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__ >/dev/null
+	    then
+		HP_ARCH="hppa2.0w"
+	    else
+		HP_ARCH="hppa64"
+	    fi
+	fi
 	echo ${HP_ARCH}-hp-hpux${HPUX_REV}
 	exit 0 ;;
     ia64:HP-UX:*:*)

Re: Patch to config.guess (2002-07-03) to detect 64bit HPUX compiler

[Ben Elliston]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

  John> There was a further problem...  I directed the output of the
  John> __LP64__ check to /dev/null.  I guess the "-q" was necessary.

I omitted the -q in my patch because according to the GNU grep manual:

  Portability note: unlike GNU grep, traditional grep did not conform
  to POSIX.2, because traditional grep lacked a -q option and its -s
  option behaved like GNU grep's -q option.  Shell scripts intended to
  be portable to traditional grep should avoid both -q and -s and
  should redirect output to /dev/null instead.

However, since we can be assured that this code will only be executing
on HP-UX (and if HP-UX's native grep supports -q), I think it can go
back in.

Ben

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

[John David Anglin]

> The toplevel configure script sets "LD=ld".  The ld used by the GCC check
> in the opcodes directory has the line 
> 
>   test -z "$LD" && LD="$ac_prog"

The above line comes from libtool.m4.  If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
GCC.  However, this define for LD isn't a proper default.  So, I am
wondering if the libtool script should also reset LD when LD=ld?

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

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

[John David Anglin]

> > The toplevel configure script sets "LD=ld".  The ld used by the GCC check
> > in the opcodes directory has the line 
> > 
> >   test -z "$LD" && LD="$ac_prog"
> 
> The above line comes from libtool.m4.  If we set LD="" in the toplevel
> configure script, the libtool script then sets LD to ld program used by
> GCC.  However, this define for LD isn't a proper default.  So, I am
> wondering if the libtool script should also reset LD when LD=ld?

After some discussion of this matter on the libtool list, the conclusion
is that Cygnus configure shouldn't be setting LD and other similar defines
in native builds.  PR 9031 has more details.

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

Re: [BFD PATCH] File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[John David Anglin]

> /* And these first appeared in hpux10.  */
> #ifndef R_SHORT_PCREL_MODE
> #define NO_PCREL_MODES
> #define R_SHORT_PCREL_MODE 0x3e
> #endif
> 
> #ifndef R_LONG_PCREL_MODE
> #define R_LONG_PCREL_MODE 0x3f
> #endif

Ooops, we don't need to define these twice.  Just define define
PA_2_0 in som.h before the a.out.h include, and see if that fixes your
problem.

The NO_PCREL_MODES define is a hack.  The generation of these two
relocs should depend on code level.  At the moment, it's not entirely
clear whether HP ld on a PA 1.X machine will link PA 2.0 code.  However,
it's possible that it was built with PA_2_0 defined and will support
the relocs.

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

[BFD PATCH] Re: File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[Stuart F. Downing]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

> > /* And these first appeared in hpux10.  */
> > #ifndef R_SHORT_PCREL_MODE
> > #define NO_PCREL_MODES
> > #define R_SHORT_PCREL_MODE 0x3e
> > #endif
> > 
> > #ifndef R_LONG_PCREL_MODE
> > #define R_LONG_PCREL_MODE 0x3f
> > #endif
> 
> Ooops, we don't need to define these twice.  Just define define
> PA_2_0 in som.h before the a.out.h include, and see if that fixes your
> problem.

Well, putting -DPA_2_0 in configure.host "fixed" my problem.  Now the
question is what is right for bfd.

> The NO_PCREL_MODES define is a hack.  

Yowsa.

> The generation of these two relocs should depend on code level.  At
> the moment, it's not entirely clear whether HP ld on a PA 1.X
> machine will link PA 2.0 code.  However, it's possible that it was
> built with PA_2_0 defined and will support the relocs.

So if I leave the hack in, but define PA_2_0 before a.out.h, then when
built on a 1.X host, if reloc.h doesn't contain the PA_2_0 conditional
code, then we won't generate these relocs.

I think that makes sense.  

Patch enclosed.  Built and tested successfully on my problem case.
-- 
Stuart Downing


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: binutils-2.13.1-hppa2x-PA_2_0.patch --]
[-- Type: text/x-patch, Size: 942 bytes --]

Index: src/bfd/ChangeLog
===================================================================
RCS file: /cvs/src/src/bfd/ChangeLog,v
retrieving revision 1.1598.2.41
diff -u -r1.1598.2.41 ChangeLog
--- src/bfd/ChangeLog	7 Nov 2002 22:30:54 -0000	1.1598.2.41
+++ src/bfd/ChangeLog	21 May 2003 19:48:23 -0000
@@ -1,3 +1,7 @@
+2003-05-21  Stuart F. Downing  <sdowning@fame.com>
+
+	* som.h: Define PA_2_0 before including a.out.h
+
 2002-11-07  Daniel Jacobowitz  <drow@mvista.com>
 
 	* configure.in: Bump version and set is_release.
Index: src/bfd/som.h
===================================================================
RCS file: /cvs/src/src/bfd/som.h,v
retrieving revision 1.5
diff -u -r1.5 som.h
--- src/bfd/som.h	10 Oct 2001 12:08:29 -0000	1.5
+++ src/bfd/som.h	21 May 2003 19:48:23 -0000
@@ -27,6 +27,9 @@
 
 #include "libhppa.h"
 
+/* Enable PA2.0 if available */
+#define PA_2_0
+
 #include <a.out.h>
 #include <lst.h>
 #include <ar.h>

Re: [BFD PATCH] File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[John David Anglin]

2003-05-21  Stuart F. Downing  <sdowning@fame.com>

	* som.h: Define PA_2_0 before including a.out.h

Installed on binutils trunk.  I tested the patch on a PA 1.1 system
running hpux 10.20.  Seems to work fine with latest headers and linker.

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

Re: [BFD PATCH] File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[Daniel Jacobowitz]

On Wed, May 21, 2003 at 11:40:40PM -0400, John David Anglin wrote:
> 2003-05-21  Stuart F. Downing  <sdowning@fame.com>
> 
> 	* som.h: Define PA_2_0 before including a.out.h
> 
> Installed on binutils trunk.  I tested the patch on a PA 1.1 system
> running hpux 10.20.  Seems to work fine with latest headers and linker.

Is this patch appropriate for the branch?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [BFD PATCH] File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[John David Anglin]

> On Wed, May 21, 2003 at 11:40:40PM -0400, John David Anglin wrote:
> > 2003-05-21  Stuart F. Downing  <sdowning@fame.com>
> > 
> > 	* som.h: Define PA_2_0 before including a.out.h
> > 
> > Installed on binutils trunk.  I tested the patch on a PA 1.1 system
> > running hpux 10.20.  Seems to work fine with latest headers and linker.
> 
> Is this patch appropriate for the branch?

It's a bug fix, but I wouldn't rate it high priority.  Does that
meet the branch rules?

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

Re: [BFD PATCH] File truncation in objcopy for hppa2.0w-hp-hpux11.11 in binutils-2.13.1

[Daniel Jacobowitz]

On Thu, May 22, 2003 at 11:57:40AM -0400, John David Anglin wrote:
> > On Wed, May 21, 2003 at 11:40:40PM -0400, John David Anglin wrote:
> > > 2003-05-21  Stuart F. Downing  <sdowning@fame.com>
> > > 
> > > 	* som.h: Define PA_2_0 before including a.out.h
> > > 
> > > Installed on binutils trunk.  I tested the patch on a PA 1.1 system
> > > running hpux 10.20.  Seems to work fine with latest headers and linker.
> > 
> > Is this patch appropriate for the branch?
> 
> It's a bug fix, but I wouldn't rate it high priority.  Does that
> meet the branch rules?

In som.h, I think it does.  You can do it or I'll get it in another
merge next week after the summit.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [committed] Add support for PCREL32 and PCREL64 relocations on PA

[John David Anglin]

Oops, missed part of the patch.  This is needed for hppa-linux.

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

2004-03-19  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* elf32-hppa.c (elf32_hppa_check_relocs): Handle R_PARISC_PCREL32.
	(final_link_relocate): Likewise.

Index: elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.111
diff -u -3 -p -r1.111 elf32-hppa.c
--- elf32-hppa.c	1 Dec 2003 06:28:23 -0000	1.111
+++ elf32-hppa.c	20 Mar 2004 00:26:55 -0000
@@ -1147,12 +1147,13 @@ elf32_hppa_check_relocs (bfd *abfd,
 	    }
 	  break;
 
-	case R_PARISC_SEGBASE: /* Used to set segment base.  */
+	case R_PARISC_SEGBASE:  /* Used to set segment base.  */
 	case R_PARISC_SEGREL32: /* Relative reloc, used for unwind.  */
 	case R_PARISC_PCREL14F: /* PC relative load/store.  */
 	case R_PARISC_PCREL14R:
 	case R_PARISC_PCREL17R: /* External branches.  */
 	case R_PARISC_PCREL21L: /* As above, and for load/store too.  */
+	case R_PARISC_PCREL32:
 	  /* We don't need to propagate the relocation if linking a
 	     shared object since these are section relative.  */
 	  continue;
@@ -3145,6 +3146,7 @@ final_link_relocate (asection *input_sec
     case R_PARISC_PCREL17R:
     case R_PARISC_PCREL14R:
     case R_PARISC_PCREL14F:
+    case R_PARISC_PCREL32:
       /* Make it a pc relative offset.  */
       value -= location;
       addend -= 8;
@@ -3238,6 +3240,7 @@ final_link_relocate (asection *input_sec
     case R_PARISC_DIR17F:
     case R_PARISC_PCREL17C:
     case R_PARISC_PCREL14F:
+    case R_PARISC_PCREL32:
     case R_PARISC_DPREL14F:
     case R_PARISC_PLABEL32:
     case R_PARISC_DLTIND14F:

Re: [PATCH] Allow reduction of fake labels on PA

[John David Anglin]

> 2004-06-10  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>
> 
> 	Bug gas/213
> 	* config/tc-hppa.c (hppa_fix_adjustable): Allow reduction of fake
> 	labels.  Fix warning.

I should have said this fix has been committed.

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

Re: hppa build broken

[John David Anglin]

> Does this help with performance on your workstation?  I've checked
> that it does the right thing but it it doesn't seem to help with
> performance on my A550.

There are still problems with the algorithm.  The enclosed little
test program writes junk in just over a minute:

real    1m3.716s
user    0m0.010s
sys     0m6.450s

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

#include <fcntl.h>
#include <unistd.h>
#define FRAG_SIZE (1024 * 1024)
int
main ()
{
  char buf[FRAG_SIZE];
  int fd, i;

  fd = open ("junk", O_WRONLY|O_CREAT);
  memset (buf, 0, FRAG_SIZE);
  for (i = 1024; i; i--)
    {
      size_t cnt = FRAG_SIZE;
      ssize_t n;
      char *p = buf;

      while (cnt)
	{
	  n = write (fd, p, cnt);
	  if (n == -1)
	    abort ();
	  cnt -= n;
	  p += n;
	}
    }
}

Re: [hppa] Fix disassembly of bb condition codes

[John David Anglin]

> > Currently binutils doesn't properly differentiate between 32-bit and 
> > 64-bit condition codes for the hppa bb insn, always disassembling the 
> > condition code as a 64-bit condition if it is in pa20 mode. This patch 
> > fixes the problem.
> 
> I don't believe the change is correct.  'B' is for 64-bit conditions.
> This affects the printed bit position.  So, printing a 32-bit code with
> a 64-bit position would be wrong.

I've committed the following change.  Tested on hppa-unknown-linux-gnu
and by visually inspecting the disassembly of some bb instructions.
Let me know if you see any problems.

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

2006-03-04  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* hppa.h (pa_opcodes): Reorder bb opcodes so that pa10 opcodes come
	first.  Correct mask of bb "B" opcode.

Index: hppa.h
===================================================================
RCS file: /cvs/src/src/include/opcode/hppa.h,v
retrieving revision 1.63
diff -u -3 -p -r1.63 hppa.h
--- hppa.h	16 Oct 2005 20:42:14 -0000	1.63
+++ hppa.h	4 Mar 2006 19:16:07 -0000
@@ -593,10 +593,10 @@ static const struct pa_opcode pa_opcodes
 { "addbf",	0xa8000000, 0xfc000000, "?dnx,b,w", pa10, 0},
 { "addibt",	0xa4000000, 0xfc000000, "?dn5,b,w", pa10, 0},
 { "addibf",	0xac000000, 0xfc000000, "?dn5,b,w", pa10, 0},
+{ "bb",		0xc0004000, 0xffe06000, "?bnx,!,w", pa10, FLAG_STRICT}, 
 { "bb",		0xc0006000, 0xffe06000, "?Bnx,!,w", pa20, FLAG_STRICT}, 
+{ "bb",		0xc4004000, 0xfc006000, "?bnx,Q,w", pa10, FLAG_STRICT}, 
 { "bb",		0xc4004000, 0xfc004000, "?Bnx,B,w", pa20, FLAG_STRICT}, 
-{ "bb",		0xc0004000, 0xffe06000, "?bnx,!,w", pa10, FLAG_STRICT}, 
-{ "bb",		0xc4004000, 0xfc004000, "?bnx,Q,w", pa10, 0}, 
 { "bvb",	0xc0004000, 0xffe04000, "?bnx,w", pa10, 0},
 { "clrbts",	0xe8004005, 0xffffffff, "", pa20, FLAG_STRICT},
 { "popbts",	0xe8004005, 0xfffff007, "$", pa20, FLAG_STRICT},

Re: [hppa] Fix disassembly of bb condition codes

[Randolph Chung]

> I've committed the following change.  Tested on hppa-unknown-linux-gnu
> and by visually inspecting the disassembly of some bb instructions.
> Let me know if you see any problems.

This works great for the testcases I tried. thanks.

randolph

Re: [hppa] Fix disassembly of bb condition codes

[Nick Hudson]

On Saturday 04 March 2006 22:15:05 John David Anglin wrote:
> > > Currently binutils doesn't properly differentiate between 32-bit and
> > > 64-bit condition codes for the hppa bb insn, always disassembling the
> > > condition code as a 64-bit condition if it is in pa20 mode. This patch
> > > fixes the problem.
> >
> > I don't believe the change is correct.  'B' is for 64-bit conditions.
> > This affects the printed bit position.  So, printing a 32-bit code with
> > a 64-bit position would be wrong.
>
> I've committed the following change.  Tested on hppa-unknown-linux-gnu
> and by visually inspecting the disassembly of some bb instructions.
> Let me know if you see any problems.

This breaks, e.g.

sign:	.equ	8

	bb	sign, 0, foo

as FLAG_STRICT is now set on all entries. Not sure what the fix is

Nick

Re: hppa unwind entries

[John David Anglin]

> Sorry, I should have chimed in when I saw Nick's message yesterday.  The
> same issue is present for 64-bit hppa targets.  See code in elf-hppa.h.

I have committed the enclosed change.  Tested on hppa64-hp-hpux11.00
and hppa-unknown-linux-gnu.

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

2007-12-28  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* elf-hppa.h (elf_hppa_osec_to_segment): New function.
	(elf_hppa_record_segment_addrs): Use elf_hppa_osec_to_segment.
	Remove ATTRIBUTE_UNUSED from abfd argument.
	* elf32-hppa.c (hppa_record_segment_addr): Likewise.

Index: elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.158
diff -u -3 -p -r1.158 elf32-hppa.c
--- elf32-hppa.c	28 Dec 2007 14:45:34 -0000	1.158
+++ elf32-hppa.c	28 Dec 2007 23:22:15 -0000
@@ -3256,7 +3256,7 @@ elf32_hppa_final_link (bfd *abfd, struct
 /* Record the lowest address for the data and text segments.  */
 
 static void
-hppa_record_segment_addr (bfd *abfd ATTRIBUTE_UNUSED,
+hppa_record_segment_addr (bfd *abfd,
 			  asection *section,
 			  void *data)
 {
@@ -3266,30 +3266,9 @@ hppa_record_segment_addr (bfd *abfd ATTR
 
   if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
     {
-      bfd_vma value;
-      struct elf_segment_map *m;
-      Elf_Internal_Phdr *p;
-
-      /* Find the segment that contains the output_section for this section.  */
-      for (m = elf_tdata (abfd)->segment_map,
-	     p = elf_tdata (abfd)->phdr;
-	   m != NULL;
-	   m = m->next, p++)
-	{
-	  int i;
-
-	  for (i = m->count - 1; i >= 0; i--)
-	    if (m->sections[i] == section->output_section)
-	      break;
-	  if (i >= 0)
-	    break;
-	}
-
-      if (m == NULL)
-        return;
+      unsigned seg = elf_hppa_osec_to_segment (abfd, section->output_section);
+      bfd_vma value = elf_tdata (abfd)->phdr[seg].p_vaddr;
 
-      value = p->p_vaddr;
-      
       if ((section->flags & SEC_READONLY) != 0)
 	{
 	  if (value < htab->text_segment_base)
Index: elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.85
diff -u -3 -p -r1.85 elf-hppa.h
--- elf-hppa.h	3 Jul 2007 14:26:40 -0000	1.85
+++ elf-hppa.h	28 Dec 2007 23:22:15 -0000
@@ -1088,6 +1088,35 @@ elf_hppa_fake_sections (bfd *abfd, Elf_I
   return TRUE;
 }
 
+/* Find the segment number in which OSEC, and output section, is
+   located.  */
+
+static unsigned
+elf_hppa_osec_to_segment (bfd *output_bfd, asection *osec)
+{
+  struct elf_segment_map *m;
+  Elf_Internal_Phdr *p;
+
+  /* Find the segment that contains the output_section.  */
+  for (m = elf_tdata (output_bfd)->segment_map,
+	 p = elf_tdata (output_bfd)->phdr;
+       m != NULL;
+       m = m->next, p++)
+    {
+      int i;
+
+      for (i = m->count - 1; i >= 0; i--)
+	if (m->sections[i] == osec)
+	  break;
+
+      if (i >= 0)
+	break;
+    }
+
+  BFD_ASSERT (m);
+  return p - elf_tdata (output_bfd)->phdr;
+}
+
 static void
 elf_hppa_final_write_processing (bfd *abfd,
 				 bfd_boolean linker ATTRIBUTE_UNUSED)
@@ -1300,25 +1329,28 @@ elf_hppa_is_dynamic_loader_symbol (const
 
 /* Record the lowest address for the data and text segments.  */
 static void
-elf_hppa_record_segment_addrs (bfd *abfd ATTRIBUTE_UNUSED,
+elf_hppa_record_segment_addrs (bfd *abfd,
 			       asection *section,
 			       void *data)
 {
-  struct elf64_hppa_link_hash_table *hppa_info;
-  bfd_vma value;
-
-  hppa_info = data;
+  struct elf64_hppa_link_hash_table *hppa_info = data;
 
-  value = section->vma - section->filepos;
+  if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
+    {
+      unsigned seg = elf_hppa_osec_to_segment (abfd, section->output_section);
+      bfd_vma value = elf_tdata (abfd)->phdr[seg].p_vaddr;
 
-  if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
-       == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
-      && value < hppa_info->text_segment_base)
-    hppa_info->text_segment_base = value;
-  else if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
-	    == (SEC_ALLOC | SEC_LOAD))
-	   && value < hppa_info->data_segment_base)
-    hppa_info->data_segment_base = value;
+      if (section->flags & SEC_READONLY)
+	{
+	  if (value < hppa_info->text_segment_base)
+	    hppa_info->text_segment_base = value;
+	}
+      else
+	{
+	  if (value < hppa_info->data_segment_base)
+	    hppa_info->data_segment_base = value;
+	}
+    }
 }
 
 /* Called after we have seen all the input files/sections, but before

Re: hppa unwind entries

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Hi John,

>> Sorry, I should have chimed in when I saw Nick's message yesterday.  The
>> same issue is present for 64-bit hppa targets.  See code in elf-hppa.h.
> 
> I have committed the enclosed change.  Tested on hppa64-hp-hpux11.00
> and hppa-unknown-linux-gnu.

Great minds think alike... I was working on a similar change, except that I 
moved the segment searching code into elf.c like the attached patch.  If you 
have no objections I will apply this version.

Cheers
   Nick



[-- Attachment #2: bfd.patch --]
[-- Type: text/x-patch, Size: 7088 bytes --]

Index: bfd/elf-bfd.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-bfd.h,v
retrieving revision 1.254
diff -c -3 -p -r1.254 elf-bfd.h
*** bfd/elf-bfd.h	15 Dec 2007 09:42:02 -0000	1.254
--- bfd/elf-bfd.h	29 Dec 2007 09:12:57 -0000
*************** extern bfd_boolean _bfd_elf_map_sections
*** 2076,2081 ****
--- 2076,2084 ----
  
  extern bfd_boolean _bfd_elf_is_function_type (unsigned int);
  
+ extern Elf_Internal_Phdr * _bfd_elf_find_segment_containing_section
+   (bfd * abfd, asection * section);
+ 
  /* Exported interface for writing elf corefile notes. */
  extern char *elfcore_write_note
    (bfd *, char *, int *, const char *, int, const void *, int);
Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.428
diff -c -3 -p -r1.428 elf.c
*** bfd/elf.c	24 Dec 2007 16:58:23 -0000	1.428
--- bfd/elf.c	29 Dec 2007 09:13:00 -0000
*************** get_program_header_size (bfd *abfd, stru
*** 3426,3431 ****
--- 3426,3454 ----
    return segs * bed->s->sizeof_phdr;
  }
  
+ /* Find the segment that contains the output_section of section.  */
+ 
+ Elf_Internal_Phdr *
+ _bfd_elf_find_segment_containing_section (bfd * abfd, asection * section)
+ {
+   struct elf_segment_map *m;
+   Elf_Internal_Phdr *p;
+ 
+   for (m = elf_tdata (abfd)->segment_map,
+ 	 p = elf_tdata (abfd)->phdr;
+        m != NULL;
+        m = m->next, p++)
+     {
+       int i;
+ 
+       for (i = m->count - 1; i >= 0; i--)
+ 	if (m->sections[i] == section)
+ 	  return p;
+     }
+ 
+   return NULL;
+ }
+ 
  /* Create a mapping from a set of sections to a program segment.  */
  
  static struct elf_segment_map *
Index: bfd/elf32-bfin.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-bfin.c,v
retrieving revision 1.25
diff -c -3 -p -r1.25 elf32-bfin.c
*** bfd/elf32-bfin.c	28 Sep 2007 08:43:45 -0000	1.25
--- bfd/elf32-bfin.c	29 Dec 2007 09:13:01 -0000
*************** _bfinfdpic_add_rofixup (bfd *output_bfd,
*** 1497,1522 ****
  static unsigned
  _bfinfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   struct elf_segment_map *m;
!   Elf_Internal_Phdr *p;
! 
!   /* Find the segment that contains the output_section.  */
!   for (m = elf_tdata (output_bfd)->segment_map,
! 	 p = elf_tdata (output_bfd)->phdr;
!        m != NULL;
!        m = m->next, p++)
!     {
!       int i;
! 
!       for (i = m->count - 1; i >= 0; i--)
! 	if (m->sections[i] == osec)
! 	  break;
! 
!       if (i >= 0)
! 	break;
!     }
  
!   return p - elf_tdata (output_bfd)->phdr;
  }
  
  inline static bfd_boolean
--- 1497,1505 ----
  static unsigned
  _bfinfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section (output_bfd, osec);
  
!   return (p != NULL) ? p - elf_tdata (output_bfd)->phdr : -1;
  }
  
  inline static bfd_boolean
Index: bfd/elf32-frv.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-frv.c,v
retrieving revision 1.58
diff -c -3 -p -r1.58 elf32-frv.c
*** bfd/elf32-frv.c	28 Sep 2007 08:43:45 -0000	1.58
--- bfd/elf32-frv.c	29 Dec 2007 09:13:02 -0000
*************** _frvfdpic_add_rofixup (bfd *output_bfd, 
*** 1341,1366 ****
  static unsigned
  _frvfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   struct elf_segment_map *m;
!   Elf_Internal_Phdr *p;
! 
!   /* Find the segment that contains the output_section.  */
!   for (m = elf_tdata (output_bfd)->segment_map,
! 	 p = elf_tdata (output_bfd)->phdr;
!        m != NULL;
!        m = m->next, p++)
!     {
!       int i;
! 
!       for (i = m->count - 1; i >= 0; i--)
! 	if (m->sections[i] == osec)
! 	  break;
! 
!       if (i >= 0)
! 	break;
!     }
  
!   return p - elf_tdata (output_bfd)->phdr;
  }
  
  inline static bfd_boolean
--- 1341,1349 ----
  static unsigned
  _frvfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section (output_bfd, osec);
  
!   return (p != NULL) ? p - elf_tdata (output_bfd)->phdr : -1;
  }
  
  inline static bfd_boolean
Index: bfd/elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.159
diff -c -3 -p -r1.159 elf32-hppa.c
*** bfd/elf32-hppa.c	28 Dec 2007 23:43:45 -0000	1.159
--- bfd/elf32-hppa.c	29 Dec 2007 09:13:03 -0000
*************** elf32_hppa_final_link (bfd *abfd, struct
*** 3256,3264 ****
  /* Record the lowest address for the data and text segments.  */
  
  static void
! hppa_record_segment_addr (bfd *abfd,
! 			  asection *section,
! 			  void *data)
  {
    struct elf32_hppa_link_hash_table *htab;
  
--- 3256,3262 ----
  /* Record the lowest address for the data and text segments.  */
  
  static void
! hppa_record_segment_addr (bfd *abfd, asection *section, void *data)
  {
    struct elf32_hppa_link_hash_table *htab;
  
*************** hppa_record_segment_addr (bfd *abfd,
*** 3266,3273 ****
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       unsigned seg = elf_hppa_osec_to_segment (abfd, section->output_section);
!       bfd_vma value = elf_tdata (abfd)->phdr[seg].p_vaddr;
  
        if ((section->flags & SEC_READONLY) != 0)
  	{
--- 3264,3277 ----
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       bfd_vma value;
!       Elf_Internal_Phdr *p;
! 
!       p = _bfd_elf_find_segment_containing_section (abfd, section->output_section);
! 
!       if (p == NULL)
!         return;
!       value = p->p_vaddr;
  
        if ((section->flags & SEC_READONLY) != 0)
  	{
Index: bfd/elfxx-ia64.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
retrieving revision 1.204
diff -c -3 -p -r1.204 elfxx-ia64.c
*** bfd/elfxx-ia64.c	24 Dec 2007 16:55:39 -0000	1.204
--- bfd/elfxx-ia64.c	29 Dec 2007 09:13:05 -0000
*************** elfNN_ia64_relocate_section (bfd *output
*** 4894,4917 ****
  	case R_IA64_SEGREL64MSB:
  	case R_IA64_SEGREL64LSB:
  	    {
- 	      struct elf_segment_map *m;
- 	      Elf_Internal_Phdr *p;
- 
  	      /* Find the segment that contains the output_section.  */
! 	      for (m = elf_tdata (output_bfd)->segment_map,
! 		     p = elf_tdata (output_bfd)->phdr;
! 		   m != NULL;
! 		   m = m->next, p++)
! 		{
! 		  int i;
! 		  for (i = m->count - 1; i >= 0; i--)
! 		    if (m->sections[i] == input_section->output_section)
! 		      break;
! 		  if (i >= 0)
! 		    break;
! 		}
  
! 	      if (m == NULL)
  		{
  		  r = bfd_reloc_notsupported;
  		}
--- 4894,4904 ----
  	case R_IA64_SEGREL64MSB:
  	case R_IA64_SEGREL64LSB:
  	    {
  	      /* Find the segment that contains the output_section.  */
! 	      Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section
! 		(input_bfd, input_section->output_section);
  
! 	      if (p == NULL)
  		{
  		  r = bfd_reloc_notsupported;
  		}

Re: hppa unwind entries

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

Hi John,

   Actually that patch will not work - it does not apply cleanly on top of your 
patch.  Here is the corrected version.

Cheers
   Nick

[-- Attachment #2: bfd.patch --]
[-- Type: text/x-patch, Size: 8978 bytes --]

Index: bfd/elf-bfd.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-bfd.h,v
retrieving revision 1.254
diff -c -3 -p -r1.254 elf-bfd.h
*** bfd/elf-bfd.h	15 Dec 2007 09:42:02 -0000	1.254
--- bfd/elf-bfd.h	29 Dec 2007 15:48:59 -0000
*************** extern bfd_boolean _bfd_elf_map_sections
*** 2076,2081 ****
--- 2076,2084 ----
  
  extern bfd_boolean _bfd_elf_is_function_type (unsigned int);
  
+ extern Elf_Internal_Phdr * _bfd_elf_find_segment_containing_section
+   (bfd * abfd, asection * section);
+ 
  /* Exported interface for writing elf corefile notes. */
  extern char *elfcore_write_note
    (bfd *, char *, int *, const char *, int, const void *, int);
Index: bfd/elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.86
diff -c -3 -p -r1.86 elf-hppa.h
*** bfd/elf-hppa.h	28 Dec 2007 23:43:45 -0000	1.86
--- bfd/elf-hppa.h	29 Dec 2007 15:48:59 -0000
*************** elf_hppa_fake_sections (bfd *abfd, Elf_I
*** 1088,1122 ****
    return TRUE;
  }
  
- /* Find the segment number in which OSEC, and output section, is
-    located.  */
- 
- static unsigned
- elf_hppa_osec_to_segment (bfd *output_bfd, asection *osec)
- {
-   struct elf_segment_map *m;
-   Elf_Internal_Phdr *p;
- 
-   /* Find the segment that contains the output_section.  */
-   for (m = elf_tdata (output_bfd)->segment_map,
- 	 p = elf_tdata (output_bfd)->phdr;
-        m != NULL;
-        m = m->next, p++)
-     {
-       int i;
- 
-       for (i = m->count - 1; i >= 0; i--)
- 	if (m->sections[i] == osec)
- 	  break;
- 
-       if (i >= 0)
- 	break;
-     }
- 
-   BFD_ASSERT (m);
-   return p - elf_tdata (output_bfd)->phdr;
- }
- 
  static void
  elf_hppa_final_write_processing (bfd *abfd,
  				 bfd_boolean linker ATTRIBUTE_UNUSED)
--- 1088,1093 ----
*************** elf_hppa_record_segment_addrs (bfd *abfd
*** 1337,1344 ****
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       unsigned seg = elf_hppa_osec_to_segment (abfd, section->output_section);
!       bfd_vma value = elf_tdata (abfd)->phdr[seg].p_vaddr;
  
        if (section->flags & SEC_READONLY)
  	{
--- 1308,1320 ----
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       bfd_vma value;
!       Elf_Internal_Phdr *p;
! 
!       p = _bfd_elf_find_segment_containing_section (abfd, section->output_section);
!       if (p == NULL)
!         return;
!       value = p->p_vaddr;
  
        if (section->flags & SEC_READONLY)
  	{
Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.428
diff -c -3 -p -r1.428 elf.c
*** bfd/elf.c	24 Dec 2007 16:58:23 -0000	1.428
--- bfd/elf.c	29 Dec 2007 15:49:02 -0000
*************** get_program_header_size (bfd *abfd, stru
*** 3426,3431 ****
--- 3426,3454 ----
    return segs * bed->s->sizeof_phdr;
  }
  
+ /* Find the segment that contains the output_section of section.  */
+ 
+ Elf_Internal_Phdr *
+ _bfd_elf_find_segment_containing_section (bfd * abfd, asection * section)
+ {
+   struct elf_segment_map *m;
+   Elf_Internal_Phdr *p;
+ 
+   for (m = elf_tdata (abfd)->segment_map,
+ 	 p = elf_tdata (abfd)->phdr;
+        m != NULL;
+        m = m->next, p++)
+     {
+       int i;
+ 
+       for (i = m->count - 1; i >= 0; i--)
+ 	if (m->sections[i] == section)
+ 	  return p;
+     }
+ 
+   return NULL;
+ }
+ 
  /* Create a mapping from a set of sections to a program segment.  */
  
  static struct elf_segment_map *
Index: bfd/elf32-bfin.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-bfin.c,v
retrieving revision 1.25
diff -c -3 -p -r1.25 elf32-bfin.c
*** bfd/elf32-bfin.c	28 Sep 2007 08:43:45 -0000	1.25
--- bfd/elf32-bfin.c	29 Dec 2007 15:49:03 -0000
*************** _bfinfdpic_add_rofixup (bfd *output_bfd,
*** 1497,1522 ****
  static unsigned
  _bfinfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   struct elf_segment_map *m;
!   Elf_Internal_Phdr *p;
! 
!   /* Find the segment that contains the output_section.  */
!   for (m = elf_tdata (output_bfd)->segment_map,
! 	 p = elf_tdata (output_bfd)->phdr;
!        m != NULL;
!        m = m->next, p++)
!     {
!       int i;
! 
!       for (i = m->count - 1; i >= 0; i--)
! 	if (m->sections[i] == osec)
! 	  break;
! 
!       if (i >= 0)
! 	break;
!     }
  
!   return p - elf_tdata (output_bfd)->phdr;
  }
  
  inline static bfd_boolean
--- 1497,1505 ----
  static unsigned
  _bfinfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section (output_bfd, osec);
  
!   return (p != NULL) ? p - elf_tdata (output_bfd)->phdr : -1;
  }
  
  inline static bfd_boolean
Index: bfd/elf32-frv.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-frv.c,v
retrieving revision 1.58
diff -c -3 -p -r1.58 elf32-frv.c
*** bfd/elf32-frv.c	28 Sep 2007 08:43:45 -0000	1.58
--- bfd/elf32-frv.c	29 Dec 2007 15:49:05 -0000
*************** _frvfdpic_add_rofixup (bfd *output_bfd, 
*** 1341,1366 ****
  static unsigned
  _frvfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   struct elf_segment_map *m;
!   Elf_Internal_Phdr *p;
! 
!   /* Find the segment that contains the output_section.  */
!   for (m = elf_tdata (output_bfd)->segment_map,
! 	 p = elf_tdata (output_bfd)->phdr;
!        m != NULL;
!        m = m->next, p++)
!     {
!       int i;
! 
!       for (i = m->count - 1; i >= 0; i--)
! 	if (m->sections[i] == osec)
! 	  break;
! 
!       if (i >= 0)
! 	break;
!     }
  
!   return p - elf_tdata (output_bfd)->phdr;
  }
  
  inline static bfd_boolean
--- 1341,1349 ----
  static unsigned
  _frvfdpic_osec_to_segment (bfd *output_bfd, asection *osec)
  {
!   Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section (output_bfd, osec);
  
!   return (p != NULL) ? p - elf_tdata (output_bfd)->phdr : -1;
  }
  
  inline static bfd_boolean
Index: bfd/elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.159
diff -c -3 -p -r1.159 elf32-hppa.c
*** bfd/elf32-hppa.c	28 Dec 2007 23:43:45 -0000	1.159
--- bfd/elf32-hppa.c	29 Dec 2007 15:49:06 -0000
*************** elf32_hppa_final_link (bfd *abfd, struct
*** 3256,3264 ****
  /* Record the lowest address for the data and text segments.  */
  
  static void
! hppa_record_segment_addr (bfd *abfd,
! 			  asection *section,
! 			  void *data)
  {
    struct elf32_hppa_link_hash_table *htab;
  
--- 3256,3262 ----
  /* Record the lowest address for the data and text segments.  */
  
  static void
! hppa_record_segment_addr (bfd *abfd, asection *section, void *data)
  {
    struct elf32_hppa_link_hash_table *htab;
  
*************** hppa_record_segment_addr (bfd *abfd,
*** 3266,3273 ****
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       unsigned seg = elf_hppa_osec_to_segment (abfd, section->output_section);
!       bfd_vma value = elf_tdata (abfd)->phdr[seg].p_vaddr;
  
        if ((section->flags & SEC_READONLY) != 0)
  	{
--- 3264,3277 ----
  
    if ((section->flags & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
      {
!       bfd_vma value;
!       Elf_Internal_Phdr *p;
! 
!       p = _bfd_elf_find_segment_containing_section (abfd, section->output_section);
! 
!       if (p == NULL)
!         return;
!       value = p->p_vaddr;
  
        if ((section->flags & SEC_READONLY) != 0)
  	{
Index: bfd/elfxx-ia64.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
retrieving revision 1.204
diff -c -3 -p -r1.204 elfxx-ia64.c
*** bfd/elfxx-ia64.c	24 Dec 2007 16:55:39 -0000	1.204
--- bfd/elfxx-ia64.c	29 Dec 2007 15:49:07 -0000
*************** elfNN_ia64_relocate_section (bfd *output
*** 4894,4917 ****
  	case R_IA64_SEGREL64MSB:
  	case R_IA64_SEGREL64LSB:
  	    {
- 	      struct elf_segment_map *m;
- 	      Elf_Internal_Phdr *p;
- 
  	      /* Find the segment that contains the output_section.  */
! 	      for (m = elf_tdata (output_bfd)->segment_map,
! 		     p = elf_tdata (output_bfd)->phdr;
! 		   m != NULL;
! 		   m = m->next, p++)
! 		{
! 		  int i;
! 		  for (i = m->count - 1; i >= 0; i--)
! 		    if (m->sections[i] == input_section->output_section)
! 		      break;
! 		  if (i >= 0)
! 		    break;
! 		}
  
! 	      if (m == NULL)
  		{
  		  r = bfd_reloc_notsupported;
  		}
--- 4894,4904 ----
  	case R_IA64_SEGREL64MSB:
  	case R_IA64_SEGREL64LSB:
  	    {
  	      /* Find the segment that contains the output_section.  */
! 	      Elf_Internal_Phdr *p = _bfd_elf_find_segment_containing_section
! 		(input_bfd, input_section->output_section);
  
! 	      if (p == NULL)
  		{
  		  r = bfd_reloc_notsupported;
  		}

Re: hppa unwind entries

[John David Anglin]

>    Actually that patch will not work - it does not apply cleanly on top of your 
> patch.  Here is the corrected version.

Yes, it's a good idea to consolidate the search in elf.c.  No objection
to changing the hppa code.  The only thing I worried about in doing this
was how to handle the case when the search failed.

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

Re: hppa unwind entries

[Nick Clifton]

Hi Dave,

> Yes, it's a good idea to consolidate the search in elf.c.  No objection
> to changing the hppa code.  The only thing I worried about in doing this
> was how to handle the case when the search failed.

How about I put back the BFD_ASSERTs that the search function does not return a 
NULL value ?

Cheers
   Nick

Re: hppa unwind entries

[John David Anglin]

> > Yes, it's a good idea to consolidate the search in elf.c.  No objection
> > to changing the hppa code.  The only thing I worried about in doing this
> > was how to handle the case when the search failed.
> 
> How about I put back the BFD_ASSERTs that the search function does not return a 
> NULL value ?

I thought that was prudent when I did my change.  I had the impression
that the original hppa code always expected a nonzero value.  I haven't
hit a circumstance where the BFD_ASSERT triggered but testing has been
somewhat limited.

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

Re: hppa unwind entries

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi Dave,

> I thought that was prudent when I did my change.  I had the impression
> that the original hppa code always expected a nonzero value.  I haven't
> hit a circumstance where the BFD_ASSERT triggered but testing has been
> somewhat limited.

Fair enough.  This is what I have checked in.

Cheers
   Nick

bfd/ChangeLog
2007-12-31  Nick Clifton  <nickc@redhat.com>

	* elf.c (_bfd_elf_find_segment_containing_section): New function:
	Scan the segment map looking for the segment containing a
	specified function.
	* elf-bfd.h: Prototype the new function.
	* elf-hppa.h (elf_hppa_osec_to_segment): Delete.
	(elf_hppa_record_segment_addrs): Use new function.
	* elf32-bfin.c (_bfdfdpic_osec_to_segment): Use new function.
	* elf32-frv.c (_frvfdpic_osec_to_segment): Use new function.
	* elf32-hppa.c (hppa_record_segment_addr): Use new function.
	* elfxx-ia64.c (elfNN_ia64_relocate_section): Use new function.

[-- Attachment #2: bfd.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 2096 bytes --]

Re: [committed] Ensure pc-relative calls can reach their target on hppa64

[John David Anglin]

I noticed in comparing the code in elf32-hppa.c to the new code that I
added for the branch offset check, that the offset calculation was off
by eight bytes.  The enclosed change fixes that error.

Tested on hppa64-hp-hpux11.11 and committed to trunk.

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

2009-02-15  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* elf-hppa.h (elf_hppa_final_link_relocate): Correct addend value used
	in branch offset check.

Index: elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.90
diff -u -3 -p -r1.90 elf-hppa.h
--- elf-hppa.h	25 Jan 2009 23:05:20 -0000	1.90
+++ elf-hppa.h	14 Feb 2009 16:40:02 -0000
@@ -1684,6 +1684,7 @@ elf_hppa_final_link_relocate (Elf_Intern
 	/* Turn VALUE into a proper PC relative address.  */
 	value -= (offset + input_section->output_offset
 		  + input_section->output_section->vma);
+	addend -= 8;
 
 	if (r_type == (unsigned int) R_PARISC_PCREL22F)
 	  max_branch_offset = (1 << (22-1)) << 2;
@@ -1708,9 +1709,9 @@ elf_hppa_final_link_relocate (Elf_Intern
 
 	/* Adjust for any field selectors.  */
 	if (r_type == R_PARISC_PCREL17R)
-	  value = hppa_field_adjust (value, -8 + addend, e_rsel);
+	  value = hppa_field_adjust (value, addend, e_rsel);
 	else
-	  value = hppa_field_adjust (value, -8 + addend, e_fsel);
+	  value = hppa_field_adjust (value, addend, e_fsel);
 
 	/* All branches are implicitly shifted by 2 places.  */
 	value >>= 2;

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.

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)