public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifix.com>
To: James Lemke <jwlemke@wasabisystems.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: intermittent 0-length for .note.gnu.arm.ident
Date: Sat, 29 Apr 2006 14:51:00 -0000	[thread overview]
Message-ID: <1146271943.15759.270.camel@aretha.corp.specifix.com> (raw)
In-Reply-To: <1146232366.28049.100.camel@winch.thelemkes.ca>

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

  reply	other threads:[~2006-04-29  0:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20  1:47 James Lemke
2006-04-20 14:40 ` Nick Clifton
2006-04-28 18:41 ` James Lemke
2006-04-29 14:51   ` James E Wilson [this message]
2006-05-01  5:35   ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1146271943.15759.270.camel@aretha.corp.specifix.com \
    --to=wilson@specifix.com \
    --cc=binutils@sourceware.org \
    --cc=jwlemke@wasabisystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).