This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Interesting.  So it might be an issue with gcc but it looks like the linker
can deal with it.  On our end, it actually turned out that the process that
was spawning ld (our bootable image generator) was using a special link
script that wasn't taking into account the presence of these sections.  When
we put them into the link script, the warnings went away and the image could
boot.  Thanks very much for the help.  I'll try out your patch and see if it
cleans up our objects for us.

cheers,

Kris

----- Original Message ----- 
From: "Alan Modra" <amodra@bigpond.net.au>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: "Gcc ML" <gcc@gcc.gnu.org>; <binutils@sources.redhat.com>
Sent: Friday, November 28, 2003 8:42 PM
Subject: Re: ppc problem with .rodata.str1.4. binutils requirement for gcc
3.3.1?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]