Re: Millicode calls, GP register, ld -r

Re: Millicode calls, GP register, ld -r

[Alan Modra]

On 10 Aug 2000, David Huggins-Daines wrote:

> Oh boy, it's worse.  It looks like $$dyncall has been clobbering %r19
> with bogus values all along, actually, because we're only using four
> bytes for our PLABELs, and it wants to load the linkage table pointer
> from the second (non-existent) word:
>

Hi David,

On thinking about this $$dyncall issue a bit more, what use are PLABELs in
PIC code anyway?  As far as I can see, PLABELs are used for two things:
1) to provide an unique address for a function
2) as a place to hang argument relocation information

We're not doing (2), and (1) is satisfied by the value in the PLTGOT.

So...  I can turn a PLABEL reference into a GOT reference, which will
magically fix the $$dyncall problem.

Comments?

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: Millicode calls, GP register, ld -r

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0008111648380.29780-100000@front.linuxcare.com.au>y
ou write:
  > 
  > Hi David,
  > 
  > On thinking about this $$dyncall issue a bit more, what use are PLABELs in
  > PIC code anyway?  As far as I can see, PLABELs are used for two things:
  > 1) to provide an unique address for a function
  > 2) as a place to hang argument relocation information
  > 
  > We're not doing (2), and (1) is satisfied by the value in the PLTGOT.
  > 
  > So...  I can turn a PLABEL reference into a GOT reference, which will
  > magically fix the $$dyncall problem.
  > 
  > Comments?
The other way it's used is to handle intra-space calls/returns.  I don't know
if that's an issue for y'all or not.

jeff

jeff

Re: Millicode calls, GP register, ld -r

[Matthew Wilcox]

On Fri, Aug 11, 2000 at 06:30:36AM -0600, Jeffrey A Law wrote:
> The other way it's used is to handle intra-space calls/returns.  I don't know
> if that's an issue for y'all or not.

we just use one space for each process, so we never call into a different
space, except to do syscalls.

-- 
Revolutions do not require corporate support.

Re: Millicode calls, GP register, ld -r

[John David Anglin]

> 
> On Fri, Aug 11, 2000 at 06:30:36AM -0600, Jeffrey A Law wrote:
> > The other way it's used is to handle intra-space calls/returns.  I don't know
> > if that's an issue for y'all or not.
> 
> we just use one space for each process, so we never call into a different
> space, except to do syscalls.

You might want to look at the code following line 6319 in pa.md (gcc 2.96)
to see that it does what you want for EH handling under linux.  This is for
builtin_longjmp.

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

Re: Millicode calls, GP register, ld -r

[David Huggins-Daines]

Alan Modra <alan@linuxcare.com.au> writes:

> So...  I can turn a PLABEL reference into a GOT reference, which will
> magically fix the $$dyncall problem.

Yes, that's the right idea.  However it only works for external
symbols, and you still need a PLABEL32 relocation for function
pointers to local symbols within a shared object (like dl_main for
instance, hint hint :-)

I'll try to take a shot at it but I still don't fully comprehend the
BFD code.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: Millicode calls, GP register, ld -r

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> Alan Modra <alan@linuxcare.com.au> writes:
> 
> > So...  I can turn a PLABEL reference into a GOT reference, which will
> > magically fix the $$dyncall problem.
> 
> Yes, that's the right idea.  However it only works for external
> symbols, and you still need a PLABEL32 relocation for function
> pointers to local symbols within a shared object (like dl_main for
> instance, hint hint :-)
> 
> I'll try to take a shot at it but I still don't fully comprehend the
> BFD code.

Here's an (ugly) patch that works.  Please verify that the last chunk
is okay - ld was outputting bogus PLABEL32 relocations when things
were compiled with -ffunction-sections, because it was effectively
calculating the addend as the offset within the input section.

With this patch ld.so manages to link itself again.

Index: bfd/elf32-hppa.c
===================================================================
RCS file: /home/cvs/parisc/binutils-2.10/bfd/elf32-hppa.c,v
retrieving revision 1.13.2.25
diff -u -r1.13.2.25 elf32-hppa.c
--- elf32-hppa.c	2000/08/11 18:12:40	1.13.2.25
+++ elf32-hppa.c	2000/08/12 04:28:20
@@ -1058,9 +1058,14 @@
 	    }
 	  break;
 
+	case R_PARISC_PLABEL32:
+	  /* In this case, if it's local, we don't need a .plt entry,
+             but we might need to generate a dynamic relocation. */
+	  if (h == NULL)
+	    goto local_plabel;
+
 	case R_PARISC_PLABEL14R: /* "Official" procedure labels.  */
 	case R_PARISC_PLABEL21L:
-	case R_PARISC_PLABEL32:
 	case R_PARISC_PCREL17C:
 	case R_PARISC_PCREL17F:
 	case R_PARISC_PCREL22F:
@@ -1131,6 +1136,7 @@
 	  /* Fall through.  */
 #endif
 
+	local_plabel:
 	case R_PARISC_DIR32: /* .word, PARISC.unwind relocs.  */
 
 	  /* Flag this symbol as having a non-got, non-plt reference
@@ -2738,12 +2744,16 @@
 			 + hplink->sgot->output_section->vma);
 	  break;
 
+	case R_PARISC_PLABEL32:
+	  /* As in check_relocs, we may need to output a dynamic reloc
+             here even for local symbols. */
+	  if (h == NULL)
+	    goto local_plabel;
 	case R_PARISC_PLABEL14R:
 	case R_PARISC_PLABEL21L:
-	case R_PARISC_PLABEL32:
 	  if (elf_hash_table (info)->dynamic_sections_created
 	      && h != NULL
-	      && h->elf.plt.offset != -1)
+	      && h->elf.plt.offset != (bfd_vma) -1)
 	    {
 	      /* PLABELs contain function pointers.  Relocation is to
 		 the entry for the function in the .plt.  The magic +2
@@ -2756,6 +2766,7 @@
 	    }
 	  break;
 
+	local_plabel:
 	case R_PARISC_DIR17F:
 	case R_PARISC_DIR17R:
 	case R_PARISC_DIR14R:
@@ -2832,14 +2843,18 @@
 		{
 		  int indx = 0;
 
+		  /* Add the absolute offset of the symbol. */
+		  outrel.r_addend += relocation;
+
 		  if (! bfd_is_abs_section (sym_sec))
 		    {
 		      indx = elf_section_data (sym_sec->output_section)->dynindx;
-		      outrel.r_addend -= (sym_sec->output_offset
-					  + sym_sec->output_section->vma);
+		      /* Subtract out the output section's address (but
+                         not the offset of the input section in the
+                         output section!). */
+		      outrel.r_addend -= sym_sec->output_section->vma;
 		    }
 
-		  outrel.r_addend += relocation;
 		  outrel.r_info = ELF32_R_INFO (indx, r_type);
 		}
 


-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: Millicode calls, GP register, ld -r

[Alan Modra]

On 11 Aug 2000, David Huggins-Daines wrote:

> Here's an (ugly) patch that works.  Please verify that the last chunk

Looks OK to me.

-- 
Linuxcare.  Support for the Revolution.

Re: Millicode calls, GP register, ld -r

[Alan Modra]

On Sat, 12 Aug 2000, Alan Modra wrote:

> On 11 Aug 2000, David Huggins-Daines wrote:
> 
> > Here's an (ugly) patch that works.  Please verify that the last chunk
> 
> Looks OK to me.

I'll install a slightly modified version of your patch.  The other PLABEL
relocs should be handled as for PLABEL32, not that it matters for gcc
output as I've never caught gcc generating code that used PLABEL14R and
PLABEL21L.  A pity, because current gcc PIC code for handling function
pointers is rather inefficient.  Typically, you get something like:

.LC1:
        .word P'bar
.
.
        addil LT'.LC1,%r19
        ldw RT'.LC1(%r1),%r22
        ldw 0(%r22),%r22

which could all be replaced with

	ldil LP'bar,%r22
	ldo RP'bar(%r22),%r22

saving on code size, memory accesses, and relocs.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: Millicode calls, GP register, ld -r

[David Huggins-Daines]

Alan Modra <alan@linuxcare.com.au> writes:

> I'll install a slightly modified version of your patch.  The other PLABEL
> relocs should be handled as for PLABEL32, not that it matters for gcc
> output as I've never caught gcc generating code that used PLABEL14R and
> PLABEL21L.  A pity, because current gcc PIC code for handling function
> pointers is rather inefficient.  Typically, you get something like:
> 
> .LC1:
>         .word P'bar
> .
> .
>         addil LT'.LC1,%r19
>         ldw RT'.LC1(%r1),%r22
>         ldw 0(%r22),%r22
> 
> which could all be replaced with
> 
> 	ldil LP'bar,%r22
> 	ldo RP'bar(%r22),%r22
> 
> saving on code size, memory accesses, and relocs.

Interesting.  It would be trivial to hack that into GCC, I just wonder
if there's some good reason it hasn't been done before.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: Millicode calls, GP register, ld -r

[John David Anglin]

> Alan Modra <alan@linuxcare.com.au> writes:
> 
> > I'll install a slightly modified version of your patch.  The other PLABEL
> > relocs should be handled as for PLABEL32, not that it matters for gcc
> > output as I've never caught gcc generating code that used PLABEL14R and
> > PLABEL21L.  A pity, because current gcc PIC code for handling function
> > pointers is rather inefficient.  Typically, you get something like:
> > 
> > .LC1:
> >         .word P'bar
> > .
> > .
> >         addil LT'.LC1,%r19
> >         ldw RT'.LC1(%r1),%r22
> >         ldw 0(%r22),%r22
> > 
> > which could all be replaced with
> > 
> > 	ldil LP'bar,%r22
> > 	ldo RP'bar(%r22),%r22
> > 
> > saving on code size, memory accesses, and relocs.
> 
> Interesting.  It would be trivial to hack that into GCC, I just wonder
> if there's some good reason it hasn't been done before.

The HP linker `-O' option eliminates unnecessary ADDIL instructions and
dead procedures.  Probably, it wasn't deemed necessary.  However, not
many remember to include -Wl,-O in their link flags.

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

Re: Millicode calls, GP register, ld -r

[David Huggins-Daines]

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

> The HP linker `-O' option eliminates unnecessary ADDIL instructions

Yes, currently our code generation is absolute crap, because we are
using ADDIL+LDO sequences for absolutely every DP or DLT
relative/indirect access.

Other BFD and GCC targets have optimizations to use 'short' data, bss,
got, and sometimes plt sections when possible.  Long term I would
really like to implement this for hppa-linux.

I'm not at all sure how this is done though - can anyone point me to
some code or documentation that explains it?

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: Millicode calls, GP register, ld -r

[Jeffrey A Law]

  In message <87punemrk8.fsf@linuxcare.com>you write:
  > Alan Modra <alan@linuxcare.com.au> writes:
  > 
  > > I'll install a slightly modified version of your patch.  The other PLABEL
  > > relocs should be handled as for PLABEL32, not that it matters for gcc
  > > output as I've never caught gcc generating code that used PLABEL14R and
  > > PLABEL21L.  A pity, because current gcc PIC code for handling function
  > > pointers is rather inefficient.  Typically, you get something like:
  > > 
  > > .LC1:
  > >         .word P'bar
  > > .
  > > .
  > >         addil LT'.LC1,%r19
  > >         ldw RT'.LC1(%r1),%r22
  > >         ldw 0(%r22),%r22
  > > 
  > > which could all be replaced with
  > > 
  > > 	ldil LP'bar,%r22
  > > 	ldo RP'bar(%r22),%r22
  > > 
  > > saving on code size, memory accesses, and relocs.
  > 
  > Interesting.  It would be trivial to hack that into GCC, I just wonder
  > if there's some good reason it hasn't been done before.
"inline plabels" used to be in GCC, but were removed a few years ago; they
were abolished roughly 4 years ago.

My recollection was that the inline plabel sequence needed for MPE was 
actually less efficient than getting the value out of memory.   And
HP didn't believe the benefit from having an inline sequence for the HPUX
calling conventions was worth the extra maintenance burden in their
compiler.  GCC (of course) followed HP's recommendations and abolished
inline plabels.

jeff