Re: intermittent 0-length for .note.gnu.arm.ident

[James E Wilson <wilson at specifix dot com>]

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