Oracle library fix

Oracle library fix

[Alan Modra]

Does anyone know whether the following 1995 code is still needed?
My guess is that the "incomprehensible reason" mentioned in the
comment is that some object had relocation sections created by hand.
With my recent commit b6d1f70cc7e any such relocation section should
have a proper sh_link field, but of course if people are still using
constructs like

 .section .rel.text,""
 .4byte reloc_offset
 .4byte reloc_number + sym_index

then I'll need to delay this cleanup for some years.

	* elf.c (bfd_section_from_shdr): Remove old hack for Oracle
	libraries.

diff --git a/bfd/elf.c b/bfd/elf.c
index 98f47da0797..e6c6a8a6c05 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -2389,40 +2389,6 @@ bfd_section_from_shdr (bfd *abfd, unsigned int shindex)
 	    goto success;
 	  }
 
-	/* For some incomprehensible reason Oracle distributes
-	   libraries for Solaris in which some of the objects have
-	   bogus sh_link fields.  It would be nice if we could just
-	   reject them, but, unfortunately, some people need to use
-	   them.  We scan through the section headers; if we find only
-	   one suitable symbol table, we clobber the sh_link to point
-	   to it.  I hope this doesn't break anything.
-
-	   Don't do it on executable nor shared library.  */
-	if ((abfd->flags & (DYNAMIC | EXEC_P)) == 0
-	    && elf_elfsections (abfd)[hdr->sh_link]->sh_type != SHT_SYMTAB
-	    && elf_elfsections (abfd)[hdr->sh_link]->sh_type != SHT_DYNSYM)
-	  {
-	    unsigned int scan;
-	    int found;
-
-	    found = 0;
-	    for (scan = 1; scan < num_sec; scan++)
-	      {
-		if (elf_elfsections (abfd)[scan]->sh_type == SHT_SYMTAB
-		    || elf_elfsections (abfd)[scan]->sh_type == SHT_DYNSYM)
-		  {
-		    if (found != 0)
-		      {
-			found = 0;
-			break;
-		      }
-		    found = scan;
-		  }
-	      }
-	    if (found != 0)
-	      hdr->sh_link = found;
-	  }
-
 	/* Get the symbol table.  */
 	if ((elf_elfsections (abfd)[hdr->sh_link]->sh_type == SHT_SYMTAB
 	     || elf_elfsections (abfd)[hdr->sh_link]->sh_type == SHT_DYNSYM)

-- 
Alan Modra
Australia Development Lab, IBM

Re: Oracle library fix

[Jose E. Marchesi]

Hi Alan.

> Does anyone know whether the following 1995 code is still needed?
> My guess is that the "incomprehensible reason" mentioned in the
> comment is that some object had relocation sections created by hand.
> With my recent commit b6d1f70cc7e any such relocation section should
> have a proper sh_link field, but of course if people are still using
> constructs like
>
>  .section .rel.text,""
>  .4byte reloc_offset
>  .4byte reloc_number + sym_index
>
> then I'll need to delay this cleanup for some years.

I just asked internally about this.
Will let you know what I find out.

Re: Oracle library fix

[Jose E. Marchesi]

Hi Alan.

>> Does anyone know whether the following 1995 code is still needed?
>> My guess is that the "incomprehensible reason" mentioned in the
>> comment is that some object had relocation sections created by hand.
>> With my recent commit b6d1f70cc7e any such relocation section should
>> have a proper sh_link field, but of course if people are still using
>> constructs like
>>
>>  .section .rel.text,""
>>  .4byte reloc_offset
>>  .4byte reloc_number + sym_index
>>
>> then I'll need to delay this cleanup for some years.
>
> I just asked internally about this.
> Will let you know what I find out.

These are the findings:

As for Sun's compilers, assemblers and linkers, we have never heard of
that.  The Solaris linkers don't contain any code like that.

As for Oracle Database, we are not aware of shipping objects with
relocation sections having incorrect sh_link or using hand-crafted
relocation sections.

It would be interesting to know what objects triggered the need for the
workaround, but being the hack so old we will probably never know.

All in all, I would say it is perfectly ok to remove that code.
Hope this is helpful.

Re: Oracle library fix

[Alan Modra]

On Fri, Dec 10, 2021 at 06:26:13PM +0100, Jose E. Marchesi wrote:
> 
> Hi Alan.
> 
> >> Does anyone know whether the following 1995 code is still needed?
> >> My guess is that the "incomprehensible reason" mentioned in the
> >> comment is that some object had relocation sections created by hand.
> >> With my recent commit b6d1f70cc7e any such relocation section should
> >> have a proper sh_link field, but of course if people are still using
> >> constructs like
> >>
> >>  .section .rel.text,""
> >>  .4byte reloc_offset
> >>  .4byte reloc_number + sym_index
> >>
> >> then I'll need to delay this cleanup for some years.
> >
> > I just asked internally about this.
> > Will let you know what I find out.
> 
> These are the findings:
> 
> As for Sun's compilers, assemblers and linkers, we have never heard of
> that.  The Solaris linkers don't contain any code like that.
> 
> As for Oracle Database, we are not aware of shipping objects with
> relocation sections having incorrect sh_link or using hand-crafted
> relocation sections.
> 
> It would be interesting to know what objects triggered the need for the
> workaround, but being the hack so old we will probably never know.
> 
> All in all, I would say it is perfectly ok to remove that code.
> Hope this is helpful.

Very helpful, thanks for doing this.  I've run
 grep '\.section[ 	"]*\.rel'
over a number of projects myself, so I'll now commit the cleanup.

-- 
Alan Modra
Australia Development Lab, IBM