From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6877 invoked by alias); 29 Apr 2006 00:52:28 -0000 Received: (qmail 6814 invoked by uid 22791); 29 Apr 2006 00:52:27 -0000 X-Spam-Check-By: sourceware.org Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO duck.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 29 Apr 2006 00:52:25 +0000 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id A6A78FA8B; Fri, 28 Apr 2006 17:52:23 -0700 (PDT) Subject: Re: intermittent 0-length for .note.gnu.arm.ident From: James E Wilson To: James Lemke Cc: "binutils@sourceware.org" In-Reply-To: <1146232366.28049.100.camel@winch.thelemkes.ca> References: <1145470462.6397.89.camel@winch.thelemkes.ca> <1146232366.28049.100.camel@winch.thelemkes.ca> Content-Type: text/plain Message-Id: <1146271943.15759.270.camel@aretha.corp.specifix.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 29 Apr 2006 14:51:00 -0000 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00425.txt.bz2 On Fri, 2006-04-28 at 06:52, James Lemke wrote: > In the usual case, the statically allocated frchainS structures will > have a lower address than all of the malloc'd ones. However, in the > MinGW environment with a lot of environment space in use, the reverse is > true placing "*UND*" at the end of the list. I reproduced this. It looked a little strange to me, but storage returned by malloc was above the data section with a small environment, and below the data section (in a large address space hole) with a large environment. I don't know why Windows does this, just that is does. > if (seginfo && seginfo->frchainP == frcP) > seginfo->frchainP = newP; It isn't obvious to me why this code is here. I guess it is trying to create some kind of ordered list, and maybe it is assuming that frchainP must be either less than frcP or equal to it here, and we only need to handle the equal case. But this fails when frchainP is NULL. If this analysis is correct, then Jim Lemke's patch looks right to me. I noticed that subseg_new always sets seginfo->frchainP if it is NULL. So this seems to lead to two possibilities, either we should have called subseg_new in the first place (and thus my suggested patch), or else the subseg_new code is redundant with this code after this code is fixed to handle the NULL case. I can't really tell at the moment, as I don't fully understand what this code is trying to do. > + #if 0 > arm_arch = bfd_make_section_old_way (stdoutput, ARM_NOTE_SECTION); > + #endif > + arm_arch = subseg_new (ARM_NOTE_SECTION, 0); This code isn't in mainline anymore, so if this is the correct fix, then no fix at all is needed in mainline. This stems from my observation that other backends seem to uniformly call subseg_new when they need a new section. And also from the fact that subseg_new handles the frchainP == NULL case correctly, so we get the right result if we use it instead of bfd_make_section_old_way and subseg_set. -- Jim Wilson, GNU Tools Support, http://www.specifix.com