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

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

[law]

 "John David Anglin" writes:

 > 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".  
Hmmm, what is the scope of do_exitcu?  global or file-local?

I vaguely recall that the behavior of these are different; specifically
the .dlt entry isn't supposed to point to a .opd entry (since we don't
have .opd entries for static functions).

 > 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?
There is some *major* hair when you take the address of a function, 
unfortunately, all the little details aren't fresh in my mind anymore.
You'd have to read the various comments throughout elf64-hppa.c.


jeff

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

[John David Anglin]

>  "John David Anglin" writes:
> 
>  > 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".  
> Hmmm, what is the scope of do_exitcu?  global or file-local?

It's local.

Symbols from exitcu.o:

[Index]    Value                  Size    Type  Bind  O Shndx    Name

[3]      |                     0|     180|FUNC |LOCAL|0|   .text|do_exitcu

> I vaguely recall that the behavior of these are different; specifically
> the .dlt entry isn't supposed to point to a .opd entry (since we don't
> have .opd entries for static functions).

That's definitely strange as the HP compiler is definitely passing a
pointer to an .opd entry for do_excite when it calls ___stdio_unsup_1.
The GNU linked code seg faults on the bve,l call to do_exitcu which
occurs here:

 36c:   50 a2 00 20     ldd 10(r5),rp
 370:   50 bb 00 30     ldd 18(r5),dp
 374:   35 9a 00 00     ldo 0(r12),r26
 378:   e8 40 f0 00     bve,l (rp),%r2

It seems that the HP compiler and linker use an .opd entry for an indirect
call to a static function in a different module.  This little test program
shows the difference between what cc +DA2.0W and gcc are doing:

extern void f (void (*)(void));
static void g (void) { }
main ()
{
  f (g);
}

cc +DA2.0W -c:

  18:   2b 60 00 00     addil 0,dp,%r1
			18: R_PARISC_LTOFF_FPTR21L      g
  1c:   50 3a 00 00     ldd 0(r1),r26
			1c: R_PARISC_LTOFF_FPTR14DR     g
  20:   e8 00 a0 00     b,l 28 <main+0x28>,%r2
			20: R_PARISC_PCREL22F   f
  24:   37 dd 3f a1     ldo -30(sp),ret1

gcc:

  40:   2b 60 00 00     addil 0,dp,%r1
			40: R_PARISC_DLTIND21L  L$C0000
  44:   50 21 00 00     ldd 0(r1),r1
			44: R_PARISC_DLTIND14R  L$C0000
  48:   0c 20 10 da     ldd 0(sr0,r1),r26
  4c:   37 dd 3f e1     ldo -10(sp),ret1
  50:   e8 00 a0 00     b,l 58 <main+0x40>,%r2
			50: R_PARISC_PCREL22F   f
  54:   08 00 02 40     nop

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 <200202120240.g1C2eWJ5023010@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > > Hmmm, what is the scope of do_exitcu?  global or file-local?
 > 
 > It's local.
OK.  That's probably the key to the varying behavior; the number of problems
I had with local function symbols was significant.



 > That's definitely strange as the HP compiler is definitely passing a
 > pointer to an .opd entry for do_excite when it calls ___stdio_unsup_1.
OK.  I was wrong -- I just found the code which special cases the address
of a local function and creates a .opd entry for it
elf64-hppa.c::allocate_global_data_opd.

      /* If we are creating a shared library, took the address of a local
         function or might export this function from this object file, then
         we have to create an opd descriptor.  */
      else if (x->info->shared
               || h == NULL
               || h->dynindx == -1
               || ((h->root.type == bfd_link_hash_defined
                    || h->root.type == bfd_link_hash_defweak)
                   && h->root.u.def.section->output_section != NULL))

I'm pretty sure the case where "h == NULL" is the local symbol check.  I
believe the h->dynindx == -1 verifies that we haven't created a dynamic
symbol (which would indicate that we've already got a .opd for this symbol).
This allocates space for the .opd entry, but doesn't initialize it.  But
verifying that we've created the .opd space is probably the first step
in debugging this problem.

In theory you should be able to set up a simple test for this and either
trace through that routine for a local function symbol that's had its
address taken.

In your example code there's a fundamental code generation difference between
GCC and HPC.

GCC puts the address of the function into the constant pool, so we have
two instructions to get the address of the pool entry, and a third insn
to extract the data (ie, the address of the .opd descriptor).  You should
have an FPTR64 relocation for g in the constant pool.

HP's compiler avoids a level of indirection by constructing the address
of the opd inline.


If you provide a stub "f" function in your example and compile it down to
an executable, you can find "g" in the opd table.  First you run nm on the
resulting binary to find the actual address of "g".  Then you run objdump -s
on the executable.  Find the .opd section  in the output, then search it for
the address of "g".  An opd entry looks like this where each entry is an
8 byte quantity:

	0
	0
	&function
	dlt value


I just did this and it looks like we've got a .opd entry for "g".

The .data section contains the address of the .opd entry, so it's likely
the constant pool entry is OK.

The .dlt section contains the address of the constant pool entry in the
.data section.  So it's probably OK.

And main references the .dlt entry in the instructions to load the
address of "g" to pass to "f".

Looking at it under the debugger, everything seems fine.  Ugh.  You'll
probably need to go through these steps with your larger example to
figure out where things go wrong.

jeff

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

[John David Anglin]

> I'm pretty sure the case where "h == NULL" is the local symbol check.  I
> believe the h->dynindx == -1 verifies that we haven't created a dynamic
> symbol (which would indicate that we've already got a .opd for this symbol).
> This allocates space for the .opd entry, but doesn't initialize it.  But
> verifying that we've created the .opd space is probably the first step
> in debugging this problem.

I have confirmed that we do in fact have a .opd entry for do_exitcu.  Thus,
The problem must be that we are doing the relocations for
R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_FPTR14DR incorrectly.  It
would appear that we are using the function address rather than the
address of the .opd entry.

I think I see the problem.  See line 1654 in elf-hppa.h.  I think we
need to use the .opd address for the LTOFF relocations, not the DLT
offset.

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 <200202121905.g1CJ59MI026367@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > I have confirmed that we do in fact have a .opd entry for do_exitcu.
OK.  Good.

 > Thus, The problem must be that we are doing the relocations for
 > R_PARISC_LTOFF_FPTR21L and R_PARISC_LTOFF_FPTR14DR incorrectly.
Maybe.

 > It would appear that we are using the function address rather than the
 > address of the .opd entry.
Most likely.

 > I think I see the problem.  See line 1654 in elf-hppa.h.  I think we
 > need to use the .opd address for the LTOFF relocations, not the DLT
 > offset.
Odd.  According to my reading of the the ABI, I believe that code is
correct.  The LTOFF_FPTR21L and LTOFF_FPTR14DR relocs should be referencing
the DLT, not accessing the .opd directly.

However, that interpretation directly conflicts with the code you found
in exitcu.o.  Ugh.

My ABI is V1.43 Oct 6, 1997.

Could you check the HP web site and see if there's a newer version and
see what formula they give for the LTOFF relocations?  You can probably
find it by searching for ELF.  You're looking for the
"Processor-Specific ELF Supplement for PA-RISC".

jeff

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.

>  > It would appear that we are using the function address rather than the
>  > address of the .opd entry.
> Most likely.
> 
>  > I think I see the problem.  See line 1654 in elf-hppa.h.  I think we
>  > need to use the .opd address for the LTOFF relocations, not the DLT
>  > offset.
> Odd.  According to my reading of the the ABI, I believe that code is
> correct.  The LTOFF_FPTR21L and LTOFF_FPTR14DR relocs should be referencing
> the DLT, not accessing the .opd directly.

You are correct.  The patch fixes the value put in the DLT entry.  We
were loading the function address into the DLT entry in all cases.  We
are supposed to load fptr () for the LTOFF_FPTR relocations.

> My ABI is V1.43 Oct 6, 1997.

I looked quite recently and that's what I got.

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

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

	* elf-hppa.h (elf_hppa_final_link_relocate): Use address of .opd
	entry as value for the DLT entry in R_PARISC_LTOFF_FPTR relocations.

--- elf-hppa.h.save	Tue Feb 12 14:20:47 2002
+++ elf-hppa.h	Tue Feb 12 15:19:24 2002
@@ -1646,11 +1646,7 @@
 	   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
@@ -1674,7 +1670,16 @@
 		bfd_put_64 (hppa_info->opd_sec->owner, value,
 			    (hppa_info->opd_sec->contents
 			     + dyn_h->opd_offset + 24));
+
+		/* 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

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

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

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

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

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

[John David Anglin]

>  In message <200202111708.g1BH8AIA009479@hiauly1.hia.nrc.ca>, "John David 
> Anglin
> " writes:
>  > I have a patch that leaves the dynamic-loader defined symbols undefined.
>  > Something additional would be needed if we actually generated a static
>  > binary and need to provide these symbols.
> Right.  This could possibly be an issue for the PA64 Linux folks, but I
> don't see it being an issue in HP-UX land.

This is what I currently have.  I don't know how to distinguish output
for linux from that for hpux.

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

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

	* elf-hppa.h (elf_hppa_is_dynamic_loader_symbol): New function.
	(elf_hppa_relocate_section): Ignore dynamic loader defined symbols.

--- elf-hppa.h.orig	Tue Feb 12 14:17:51 2002
+++ elf-hppa.h	Tue Feb 12 14:20:47 2002
@@ -75,6 +75,9 @@
 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 @@
   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 @@
 	    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;
+		}
 	    }
 	}
 

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

[law]

 In message <200202111708.g1BH8AIA009479@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > I have a patch that leaves the dynamic-loader defined symbols undefined.
 > Something additional would be needed if we actually generated a static
 > binary and need to provide these symbols.
Right.  This could possibly be an issue for the PA64 Linux folks, but I
don't see it being an issue in HP-UX land.

 > I think so.  The ones that are provided are supposed to be linker defined
 > according to the "PA-64 Runtime Supplement".  The only questionable one
 > is __TLS_SIZE.  The HP compiler provides a default value for it equal to
 > 0xc8 (at least, it does in a trivial program) while the linker script
 > provides a value of 0.  On the other hand, I presume crt0.o initializes
 > tp (cr27).  How does it find the start of .tbss?  From the elf header?
I suspect __TLS_SIZE can probably be derived by the linker from the size of
the various .t* sections.

I haven't really studied the HP thread local storage scheme, but I suspect
it doesn't need to find the start of tbss, only tdata as the TLS sections
should be used just for initializing thread local data.

I would expect cr27 to be initialized by crt0 or the kernel.

 > That's what the HP linker does.  However, I am not sure it hurts to define
 > the dynamic loader symbols in the linker.  It's definitely simpler.
It could hurt if the symbol is defined by a module that is dl_loaded at
runtime.

 > At the moment, a more serious issue is the treatment of LTOFF_* relocations
 > in static programs (see my mail on this yesterday).  We need to fix this
 > before a decision can be made on the synamic loader defined symbols.
I missed that completely (I've been on the road most of the last week).  Can
you resend it to me privately?

jeff

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

[John David Anglin]

> Since we always create a dynamic binary it should be OK to leave the symbols
> undefined -- as long as the dynamic linker defines them for us.

I have a patch that leaves the dynamic-loader defined symbols undefined.
Something additional would be needed if we actually generated a static
binary and need to provide these symbols.

> Hell, with that I wonder if defining the various magic symbols in the linker
> script like I did was the right thing to do for those older symbols.

I think so.  The ones that are provided are supposed to be linker defined
according to the "PA-64 Runtime Supplement".  The only questionable one
is __TLS_SIZE.  The HP compiler provides a default value for it equal to
0xc8 (at least, it does in a trivial program) while the linker script
provides a value of 0.  On the other hand, I presume crt0.o initializes
tp (cr27).  How does it find the start of .tbss?  From the elf header?

> 
>  > It looks like elf-hppa.h needs to be hacked but I have the sense that
>  > the generic elf code may not like undefined symbols from archive libraries.
> It should be OK to have an undefined symbol from an archive library,
> shared library or dynamic executable (as long as the symbol is never used or
> somehow defined at runtime).

That's what the HP linker does.  However, I am not sure it hurts to define
the dynamic loader symbols in the linker.  It's definitely simpler.

At the moment, a more serious issue is the treatment of LTOFF_* relocations
in static programs (see my mail on this yesterday).  We need to fix this
before a decision can be made on the synamic loader defined symbols.

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 <200202082242.g18Mg0MU005514@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > 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.
Since we always create a dynamic binary it should be OK to leave the symbols
undefined -- as long as the dynamic linker defines them for us.

Hell, with that I wonder if defining the various magic symbols in the linker
script like I did was the right thing to do for those older symbols.


 > It looks like elf-hppa.h needs to be hacked but I have the sense that
 > the generic elf code may not like undefined symbols from archive libraries.
It should be OK to have an undefined symbol from an archive library,
shared library or dynamic executable (as long as the symbol is never used or
somehow defined at runtime).

jeff

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

[amodra]

On Thu, Feb 07, 2002 at 04:57:04PM -0500, John David Anglin wrote:
> 
> I noticed that elf64hppa.sh sources hppa64linux.sh.  This doesn't seem
> correct for hpux11.

Oh well, I suppose the names should be changed.  I agree they're
misleading.

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

[John David Anglin]

> In message <200201221906.g0MJ6QN5015867@hiauly1.hia.nrc.ca>, "John David Anglin
> " writes:
>  > In looking at the gcc testresults for hppa64-hp-hpux11.00, I noticed that
>  > there is a problem with linking using binutils ld when "-static" was
>  > specified.  You get the following error:
> [ ... ]

>  > Does anyone have any suggestions on how to best handle the definition
>  > of these special symbols in ld?  I am guessing that "_end" and related
>  > symbols must already be handled because that's pretty standard.
> I'd been defining them in the PA64 specific linker emulation script
> (elf64hppa.sh).  It's likely further changes to those files will be
> needed over time to bring the PA64 GNU tools closer to conformance with
> the behavior of HP's tools.
> 
> I do know when I did the initial development that static linking worked --
> because that's what we relied upon in the early development before we 
> actually supported shared libraries.
> 
> Note that static linking still produces a "dynamic" binary for PA64.  Fun
> fun.

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.

It looks like elf-hppa.h needs to be hacked but I have the sense that
the generic elf code may not like undefined symbols from archive libraries.
Any suggestions?

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]

>  > Does anyone have any suggestions on how to best handle the definition
>  > of these special symbols in ld?  I am guessing that "_end" and related
>  > symbols must already be handled because that's pretty standard.
> I'd been defining them in the PA64 specific linker emulation script
> (elf64hppa.sh).  It's likely further changes to those files will be
> needed over time to bring the PA64 GNU tools closer to conformance with
> the behavior of HP's tools.

I noticed that elf64hppa.sh sources hppa64linux.sh.  This doesn't seem
correct for hpux11.

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]

>  > Does anyone have any suggestions on how to best handle the definition
>  > of these special symbols in ld?  I am guessing that "_end" and related
>  > symbols must already be handled because that's pretty standard.
> I'd been defining them in the PA64 specific linker emulation script
> (elf64hppa.sh).  It's likely further changes to those files will be
> needed over time to bring the PA64 GNU tools closer to conformance with
> the behavior of HP's tools.

Thanks, I will take a crack at updating this so that it's compatible
with the two systems that I am running.

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 <200201221906.g0MJ6QN5015867@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > In looking at the gcc testresults for hppa64-hp-hpux11.00, I noticed that
 > there is a problem with linking using binutils ld when "-static" was
 > specified.  You get the following error:
[ ... ]
Also note the set of symbols that are special changes based on what patches
from HP you have installed :(  The set that we handle is based on a
1999 hpux11.00 release and haven't been significantly updated over time.

Furthermore, some of the symbols have specific meanings which we don't
implement (like the TLS symbols for thread-local storage).


 > Does anyone have any suggestions on how to best handle the definition
 > of these special symbols in ld?  I am guessing that "_end" and related
 > symbols must already be handled because that's pretty standard.
I'd been defining them in the PA64 specific linker emulation script
(elf64hppa.sh).  It's likely further changes to those files will be
needed over time to bring the PA64 GNU tools closer to conformance with
the behavior of HP's tools.

I do know when I did the initial development that static linking worked --
because that's what we relied upon in the early development before we 
actually supported shared libraries.

Note that static linking still produces a "dynamic" binary for PA64.  Fun
fun.


jeff

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

[DJ Delorie]

For those that have fixed values, you can use a target-specific .s file
in libgcc.a that sets them:

	.global	foo
foo = 12

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

[John David Anglin]

In looking at the gcc testresults for hppa64-hp-hpux11.00, I noticed that
there is a problem with linking using binutils ld when "-static" was
specified.  You get the following error:

Executing on host: /xxx/gnu/gcc-3.1/objdir/gcc/xgcc -B/xxx/gnu/gcc-3.1/objdir/gc
c/ /xxx/gnu/gcc-3.1/gcc/gcc/testsuite/gcc.dg/special/gcsec-1.c  -ffunction-secti
ons -fdata-sections -Wl,--gc-sections -static   -lm   -o ./a.out    (timeout = 3
00)
/usr/lib/pa20_64/libc.a(static_vars.o)(.sdata+0x0): undefined reference to `__sy
stab'

Linking the same program with "cc +DA2.0W -Ae -noshared", I find the following
symbols from crt0.o and libc.a appear to have received special treatment:

# /usr/bin/nm a.out|grep ABS
[1164]   |                     0|       0|NOTYP|GLOB |0|     ABS|_FPU_STATUS
[1096]   |                     0|       0|NOTYP|GLOB |0|     ABS|__ARGC
[1097]   |                     0|       0|NOTYP|GLOB |0|     ABS|__ARGV
[852]    |                     0|       0|NOTYP|GLOB |0|     ABS|__CPU_KEYBITS_1
[1161]   |                     0|       0|NOTYP|GLOB |0|     ABS|__CPU_REVISION
[1142]   |                     0|       0|NOTYP|GLOB |0|     ABS|__ENVP
[757]    |                     0|       0|NOTYP|GLOB |0|     ABS|__FPU_MODEL
[1160]   |                     0|       0|NOTYP|GLOB |0|     ABS|__FPU_REVISION
[991]    |                     0|       0|NOTYP|GLOB |0|     ABS|__LOAD_INFO
[804]    |                   532|       0|NOTYP|GLOB |0|     ABS|__SYSTEM_ID
[1080]   |                     0|       0|NOTYP|GLOB |0|     ABS|__SYSTEM_ID_D
[909]    |                   200|       0|NOTYP|GLOB |0|     ABS|__TLS_SIZE
[969]    |                     0|       0|NOTYP|GLOB |0|     ABS|__TLS_SIZE_D
[1008]   |                     0|       0|NOTYP|GLOB |0|     ABS|__libdl_jmp_tbl
[699]    |                     0|       0|NOTYP|GLOB |0|     ABS|__systab
[938]    |   9223372041149791520|       0|NOTYP|GLOB |0|     ABS|_end

In crt0.o and libc.a, these are "UNDEF GLOBAL OBJECT" or
"DEFINED GLOBAL OBJECT".

The special symbols documented by the linker man page are:

_end: first address beyond the end of the program's address space.
_edata: first address beyond the initialized data.
_etext: first address beyond the program text.
end, edata and etext: defined if referred to in the program.
__TLS_SIZE: total thread local storage size.
_FPU_STATUS: initial status of the FPU status register.
__SYSTEM_ID: largest architecture revision level used by any compilation unit.

A user definition of any of these symbols is treated as an error.

Does anyone have any suggestions on how to best handle the definition
of these special symbols in ld?  I am guessing that "_end" and related
symbols must already be handled because that's pretty standard.

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