Re: ppc problem with .rodata.str1.4. binutils requirement for gcc 3.3.1?

[Alan Modra <amodra@bigpond.net.au>]

On Fri, Nov 28, 2003 at 01:07:21PM -0500, Kris Warkentin wrote:
> In the course of building some powerpc startup code we found ld complaining
> about "allocated section `.rodata.str1.4' not in segment" and "allocated
> section `.eh_frame' not in segment".  I observed that some of the objects in
> the startup had .rodata.str1.4 sections in them.  I also observed that if I
> took the ld from binutils 2.12.1 to 2.14, the problem went away.

This is very likely a bug in gcc.  I reckon that if you look at your
object file with readelf or objdump, you'll find that this .rodata
section is marked read/write.

The fix is easy.

--- gcc-ppc64-33.orig/gcc/config/rs6000/rs6000.c	2003-09-27 10:07:41.000000000 +0930
+++ gcc-ppc64-33/gcc/config/rs6000/rs6000.c	2003-11-29 12:04:22.000000000 +1030
@@ -13138,14 +13659,8 @@ rs6000_elf_section_type_flags (decl, nam
      const char *name;
      int reloc;
 {
-  unsigned int flags
-    = default_section_type_flags_1 (decl, name, reloc,
-				    flag_pic || DEFAULT_ABI == ABI_AIX);
-
-  if (TARGET_RELOCATABLE)
-    flags |= SECTION_WRITE;
-
-  return flags;
+  return default_section_type_flags_1 (decl, name, reloc,
+				       flag_pic || DEFAULT_ABI == ABI_AIX);
 }
 
 /* Record an element in the table of global constructors.  SYMBOL is


> I didn't find any talk of a hard binutils requirement for the 3.3 series of
> gcc but perhaps I missed it.  Can anyone shed some light on this?  I hope
> I'm not too astonishing in my ignorance but this .rodata.str1.x doesn't seem
> to be generated by our older gcc and I don't really know what the
> significance of it all is.

Sections like .rodata.str1.4 are generated by gcc to support merging of
duplicate constants and strings by ld.  Older gcc's won't do this, nor
will a newer gcc built for a system without the requisite ld support.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre