Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Daniel Jacobowitz]

On Tue, Jan 04, 2005 at 04:25:26PM +0100, Peter S. Mazinger wrote:
> Hello!
> 
> I have tried some versions of binutils-2.15 (up to and including 
> 2.15.94.0.2) in conjunction w/ gcc-3.3.5 and gcc-3.4.3, all combinations 
> produce text relocations on x86 (using glibc / uclibc) in shared libs.
> Can't tell if gcc or binutils produce this, maybe a linker script?
> 
> Please CC to me, thanks Peter

Have you checked whether you are actually producing text relocations,
or just setting DT_TEXTREL?  I just encountered another binutils ARM
bug which set DT_TEXTREL incorrectly.

This has nothing to do with GCC; redirected to binutils@.

-- 
Daniel Jacobowitz

Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Peter S. Mazinger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 960 bytes --]

On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:

> On Tue, Jan 04, 2005 at 04:25:26PM +0100, Peter S. Mazinger wrote:
> > Hello!
> > 
> > I have tried some versions of binutils-2.15 (up to and including 
> > 2.15.94.0.2) in conjunction w/ gcc-3.3.5 and gcc-3.4.3, all combinations 
> > produce text relocations on x86 (using glibc / uclibc) in shared libs.
> > Can't tell if gcc or binutils produce this, maybe a linker script?
> > 
> > Please CC to me, thanks Peter
> 
> Have you checked whether you are actually producing text relocations,
> or just setting DT_TEXTREL?  I just encountered another binutils ARM
> bug which set DT_TEXTREL incorrectly.

I have checked: readelf -d file | grep TEXT

I have seen also discrepancies between arm and other archs, and used the 
attached patch too, but nothing changes

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

[-- Attachment #2: Type: TEXT/PLAIN, Size: 616 bytes --]

--- bfd/elf32-arm.c.mps	2004-12-10 20:56:47.000000000 +0100
+++ bfd/elf32-arm.c	2004-12-10 20:57:41.000000000 +0100
@@ -4949,7 +4949,6 @@
 	      || !add_dynamic_entry (DT_RELSZ, 0)
 	      || !add_dynamic_entry (DT_RELENT, sizeof (Elf32_External_Rel)))
 	    return FALSE;
-	}
 
       /* If any dynamic relocs apply to a read-only section,
 	 then we need a DT_TEXTREL entry.  */
@@ -4961,10 +4960,10 @@
 	{
 	  if (!add_dynamic_entry (DT_TEXTREL, 0))
 	    return FALSE;
-	  info->flags |= DF_TEXTREL;
+	}
 	}
     }
-#undef add_synamic_entry
+#undef add_dynamic_entry
 
   return TRUE;
 }

Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Daniel Jacobowitz]

On Tue, Jan 04, 2005 at 06:16:56PM +0100, Peter S. Mazinger wrote:
> On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> 
> > On Tue, Jan 04, 2005 at 04:25:26PM +0100, Peter S. Mazinger wrote:
> > > Hello!
> > > 
> > > I have tried some versions of binutils-2.15 (up to and including 
> > > 2.15.94.0.2) in conjunction w/ gcc-3.3.5 and gcc-3.4.3, all combinations 
> > > produce text relocations on x86 (using glibc / uclibc) in shared libs.
> > > Can't tell if gcc or binutils produce this, maybe a linker script?
> > > 
> > > Please CC to me, thanks Peter
> > 
> > Have you checked whether you are actually producing text relocations,
> > or just setting DT_TEXTREL?  I just encountered another binutils ARM
> > bug which set DT_TEXTREL incorrectly.
> 
> I have checked: readelf -d file | grep TEXT

Then could you check whether any of the relocations are actually in the
text segment?

-- 
Daniel Jacobowitz

Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Peter S. Mazinger]

On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:

> On Tue, Jan 04, 2005 at 06:16:56PM +0100, Peter S. Mazinger wrote:
> > On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> > 
> > > On Tue, Jan 04, 2005 at 04:25:26PM +0100, Peter S. Mazinger wrote:
> > > > Hello!
> > > > 
> > > > I have tried some versions of binutils-2.15 (up to and including 
> > > > 2.15.94.0.2) in conjunction w/ gcc-3.3.5 and gcc-3.4.3, all combinations 
> > > > produce text relocations on x86 (using glibc / uclibc) in shared libs.
> > > > Can't tell if gcc or binutils produce this, maybe a linker script?
> > > > 
> > > > Please CC to me, thanks Peter
> > > 
> > > Have you checked whether you are actually producing text relocations,
> > > or just setting DT_TEXTREL?  I just encountered another binutils ARM
> > > bug which set DT_TEXTREL incorrectly.
> > 
> > I have checked: readelf -d file | grep TEXT
> 
> Then could you check whether any of the relocations are actually in the
> text segment?

How to do that?

Could you provide me a patch for the ARM bug you have found (setting 
DT_TEXTREL incorrectly)?

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Peter S. Mazinger]

On Wed, 5 Jan 2005, Peter S. Mazinger wrote:

> On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> 
> > On Tue, Jan 04, 2005 at 06:16:56PM +0100, Peter S. Mazinger wrote:
> > > On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> > > 
> > > > On Tue, Jan 04, 2005 at 04:25:26PM +0100, Peter S. Mazinger wrote:
> > > > > Hello!
> > > > > 
> > > > > I have tried some versions of binutils-2.15 (up to and including 
> > > > > 2.15.94.0.2) in conjunction w/ gcc-3.3.5 and gcc-3.4.3, all combinations 
> > > > > produce text relocations on x86 (using glibc / uclibc) in shared libs.
> > > > > Can't tell if gcc or binutils produce this, maybe a linker script?
> > > > > 
> > > > > Please CC to me, thanks Peter
> > > > 
> > > > Have you checked whether you are actually producing text relocations,
> > > > or just setting DT_TEXTREL?  I just encountered another binutils ARM
> > > > bug which set DT_TEXTREL incorrectly.
> > > 
> > > I have checked: readelf -d file | grep TEXT
> > 
> > Then could you check whether any of the relocations are actually in the
> > text segment?
> 
> How to do that?
> 
> Could you provide me a patch for the ARM bug you have found (setting 
> DT_TEXTREL incorrectly)?

Nothing changed in the meantime ;-(
I have tested binutils-cvs (as of 20050222) and no better.

Finally it seems that the DT_TEXTREL entry is coming from assembler 
sources, C code seems to be linked correctly.

on another note:
MAXPAGESIZE=0x8000 (as of bfd/elf.c) for arm, please change that in 
ld/emulparams/armelf.sh.

please CC to me, not on list.

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

PATCH for Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Daniel Jacobowitz]

On Mon, Mar 14, 2005 at 12:44:39PM +0100, Peter S. Mazinger wrote:
> On Wed, 5 Jan 2005, Peter S. Mazinger wrote:
> 
> > On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> > > Then could you check whether any of the relocations are actually in the
> > > text segment?
> > 
> > How to do that?

Via readelf.  readelf -l will show you the offsets and sizes of the
segments.  readelf -Dr will show you the offsets of relocation entries. 
Are any in the text segment?

> > 
> > Could you provide me a patch for the ARM bug you have found (setting 
> > DT_TEXTREL incorrectly)?

Attached.

This is patch 2/2 for today's duplicated-code-in-BFD hatred series.  I
tried to resync with other ports' copies of this code and it proved
surprisingly twisty, so I took the simple way out.  We were creating
reloc_copied structures with ->count = 0, which are useless and messed
up the counting algorithm.

Tested arm-linux, binutils and glibc testsuites.  Richard or Nick, is
this patch OK?

> Nothing changed in the meantime ;-(
> I have tested binutils-cvs (as of 20050222) and no better.
> 
> Finally it seems that the DT_TEXTREL entry is coming from assembler 
> sources, C code seems to be linked correctly.

Your assembly sources may be broken (non-PIC) then.

> on another note:
> MAXPAGESIZE=0x8000 (as of bfd/elf.c) for arm, please change that in 
> ld/emulparams/armelf.sh.

Nathan noticed the odd MAXPAGESIZE setting in arm-elf today also.  I
don't know the history.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-03-18  Daniel Jacobowitz  <dan@codesourcery.com>

	* elf32-arm.c (elf32_arm_check_relocs): Increment count for all
	relocation types.  Don't count relocations which will use a PLT.

Index: binutils/bfd/elf32-arm.c
===================================================================
--- binutils.orig/bfd/elf32-arm.c	2005-03-18 13:20:03.152084693 -0500
+++ binutils/bfd/elf32-arm.c	2005-03-18 17:00:25.694851664 -0500
@@ -4093,18 +4093,9 @@ elf32_arm_check_relocs (bfd *abfd, struc
                relocs_copied field of the hash table entry.  */
 	    if ((info->shared || htab->root.is_relocatable_executable)
 		&& (sec->flags & SEC_ALLOC) != 0
-		&& ((r_type != R_ARM_PC24
-		     && r_type != R_ARM_PLT32
-#ifndef OLD_ARM_ABI
-		     && r_type != R_ARM_CALL
-		     && r_type != R_ARM_JUMP24
-		     && r_type != R_ARM_PREL31
-#endif
-		     && r_type != R_ARM_REL32
-		     && r_type != R_ARM_THM_PC22)
-		    || (h != NULL
-			&& (! info->symbolic
-			    || !h->def_regular))))
+		&& (r_type == R_ARM_ABS32
+		    || (h != NULL && ! h->needs_plt
+			&& (! info->symbolic || ! h->def_regular))))
 	      {
 		struct elf32_arm_relocs_copied *p, **head;
 
@@ -4184,9 +4175,7 @@ elf32_arm_check_relocs (bfd *abfd, struc
 		    p->count = 0;
 		  }
 
-		if (r_type == R_ARM_ABS32
-		    || r_type == R_ARM_REL32)
-		  p->count += 1;
+		p->count += 1;
 	      }
 	    break;
 

Re: PATCH for Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Peter S. Mazinger]

On Fri, 18 Mar 2005, Daniel Jacobowitz wrote:

> On Mon, Mar 14, 2005 at 12:44:39PM +0100, Peter S. Mazinger wrote:
> > On Wed, 5 Jan 2005, Peter S. Mazinger wrote:
> > 
> > > On Tue, 4 Jan 2005, Daniel Jacobowitz wrote:
> > > > Then could you check whether any of the relocations are actually in the
> > > > text segment?
> > > 
> > > How to do that?
> 
> Via readelf.  readelf -l will show you the offsets and sizes of the
> segments.  readelf -Dr will show you the offsets of relocation entries. 
> Are any in the text segment?
> 
> > > 
> > > Could you provide me a patch for the ARM bug you have found (setting 
> > > DT_TEXTREL incorrectly)?
> 
> Attached.
> 
> This is patch 2/2 for today's duplicated-code-in-BFD hatred series.  I
> tried to resync with other ports' copies of this code and it proved
> surprisingly twisty, so I took the simple way out.  We were creating
> reloc_copied structures with ->count = 0, which are useless and messed
> up the counting algorithm.
> 
> Tested arm-linux, binutils and glibc testsuites.  Richard or Nick, is
> this patch OK?

tested on uclibc, it "removes" the false DT_TEXTREL from shared libs.

> 
> > Nothing changed in the meantime ;-(
> > I have tested binutils-cvs (as of 20050222) and no better.
> > 
> > Finally it seems that the DT_TEXTREL entry is coming from assembler 
> > sources, C code seems to be linked correctly.
> 
> Your assembly sources may be broken (non-PIC) then.

it was, but now it was detectable ;)

> 
> > on another note:
> > MAXPAGESIZE=0x8000 (as of bfd/elf.c) for arm, please change that in 
> > ld/emulparams/armelf.sh.
> 
> Nathan noticed the odd MAXPAGESIZE setting in arm-elf today also.  I
> don't know the history.

Please inform me, if you change that (well, I am using it w/ that value 
now, the newly added arm stuff also uses it as 0x8000, not as 256)

Thanks Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: PATCH for Re: binutils 2.15 / gcc-3.3.5 (3.4.3) produce text relocations on arm

[Richard Earnshaw]

On Fri, 2005-03-18 at 22:07, Daniel Jacobowitz wrote:

> > on another note:
> > MAXPAGESIZE=0x8000 (as of bfd/elf.c) for arm, please change that in 
> > ld/emulparams/armelf.sh.
> 
> Nathan noticed the odd MAXPAGESIZE setting in arm-elf today also.  I
> don't know the history.

It probably dates back to the days of the ARM2 and ARM3.  The memory
management chip in those days was a device called MEMC which wasn't
integrated into the CPU.  MEMC had some odd quirks and one of them was
that the page size was variable depending on the amount of memory that
had to be managed.  By using 32K pages you could manage up to 4Mb of RAM
(I think 32K was the largest supported size - above that you had to add
a second MEMC chip to the machine).

For most people this is somewhat academic now, but there are a few
people out there that use ELF on the old chips.

R.