From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27496 invoked by alias); 29 Nov 2003 01:42:58 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 27464 invoked from network); 29 Nov 2003 01:42:56 -0000 Received: from unknown (HELO bubble.modra.org) (144.136.188.60) by sources.redhat.com with SMTP; 29 Nov 2003 01:42:56 -0000 Received: by bubble.modra.org (Postfix, from userid 500) id 1413529AA2; Sat, 29 Nov 2003 12:12:55 +1030 (CST) Date: Sat, 29 Nov 2003 01:42:00 -0000 From: Alan Modra To: Kris Warkentin Cc: Gcc ML , binutils@sources.redhat.com Subject: Re: ppc problem with .rodata.str1.4. binutils requirement for gcc 3.3.1? Message-ID: <20031129014255.GT2508@bubble.sa.bigpond.net.au> Mail-Followup-To: Kris Warkentin , Gcc ML , binutils@sources.redhat.com References: <087e01c3b5da$77d658e0$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <087e01c3b5da$77d658e0$0202040a@catdog> User-Agent: Mutt/1.4i X-SW-Source: 2003-11/txt/msg00500.txt.bz2 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