From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14598 invoked by alias); 29 Nov 2003 18:14:51 -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 14585 invoked from network); 29 Nov 2003 18:14:50 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 29 Nov 2003 18:14:50 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id NAA13756; Sat, 29 Nov 2003 13:27:56 -0500 Received: from dash ([192.168.20.33]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA04466; Sat, 29 Nov 2003 13:14:47 -0500 Message-ID: <002c01c3b6a4$c2232200$6400a8c0@dash> From: "Kris Warkentin" To: "Alan Modra" Cc: "Gcc ML" , References: <087e01c3b5da$77d658e0$0202040a@catdog> <20031129014255.GT2508@bubble.sa.bigpond.net.au> Subject: Re: ppc problem with .rodata.str1.4. binutils requirement for gcc 3.3.1? Date: Sat, 29 Nov 2003 18:14:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-11/txt/msg00512.txt.bz2 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" To: "Kris Warkentin" Cc: "Gcc ML" ; 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 >