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

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

[James Lemke]

I've been looking at an oddball problem and I'm wondering if anyone here
has some ideas.

I'm building a mingw x xscale-elf toolchain and some of the objects have
normal .note.gnu.arm.ident sections (length 0x1c) and others have those
section with length 0.  The objects with 0-length sections seem to be
normal otherwise.  If I ignore linker warnings the DejaGNU tests run OK.

I never get 0-length sections for cygwin x xscale-elf from the same
sources.

One place the 0-length note sections show up often is:
<build-dir>/xscale-elf/libstdc++-v3/libsupc++/*.o

If I manually re-compile one of the 0-length .o's, it always produces a
section with 0x1c length.  As does a make in that directory.  But a
top-level make gives the random sometimes 0-length note sections.

arm_add_note() gets called with the same parms for both zero & non-zero
cases.  So what would cause the contents to disappear?

I've tried various versions of MinGW packages without making a
difference.
I'm currently using the latest mingw binary packages and my sources are:
gcc-4.0  binutils-2.15  plus local mods.

Any ideas or suggestions?

TIA,
Jim.

-- 
Jim Lemke   jwlemke@wasabisystems.com   Orillia, Ontario

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

[Nick Clifton]

Hi James,

> If I manually re-compile one of the 0-length .o's, it always produces a
> section with 0x1c length.  As does a make in that directory.  But a
> top-level make gives the random sometimes 0-length note sections.

This sounds like memory corruption of some kind.  I would suggest 
enabling memory debugging if you have that support available, or else 
adding some debugging of your own.

> arm_add_note() gets called with the same parms for both zero & non-zero
> cases.  So what would cause the contents to disappear?

Note - the arm_add_note() function was removed a while ago, so you may 
find that upgrading to newer binutils sources will solve this problem 
for you.

Cheers
   Nick

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

[James Lemke]

On Wed, 2006-04-19 at 14:14 -0400, James Lemke wrote:
:
> I'm building a mingw x xscale-elf toolchain and some of the objects have
> normal .note.gnu.arm.ident sections (length 0x1c) and others have those
> section with length 0.  The objects with 0-length sections seem to be
> normal otherwise.  If I ignore linker warnings the DejaGNU tests run OK.

Jim Wilson suggested that it might be the amount of environment space in
use that was causing the difference.  He was correct... if I consume
about 14K of env space, gas fails everytime.  (binutils-2.15)

The problems centre on gas/subsegs.c:subseg_set_rest().  It keeps a
linked list of segment / section fragments that is sorted and searched
by the addresses of the frchainS structures.

There are two sources for the frchainS structures that are stored on
this list.  Some, like "*UND*", are globally declared.  Most, like .text
and .note.gnu.arm.ident, are dynamically allocated.

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.

".note.gnu.arm.ident" is subsequently added to this list.  In the normal
case the search hits the end of the list where it is appended.  In the
failing case the new section is inserted before "*UND*".  This works
properly except here:
#ifdef BFD_ASSEMBLER
      {
        segment_info_type *seginfo;
        seginfo = seg_info (seg);
        if (seginfo && seginfo->frchainP == frcP)
          seginfo->frchainP = newP;
      }
#endif

seginfo->frchainP is NULL for the new section.  In the normal case frcP
is also NULL because we hit the end of the list and seginfo->frchainP is
updated.  In the failing case frcP is a pointer to "*UND*".  Therefore,
seginfo->frchainP remains NULL.
Therefore the section's contents are never written out.

It looks like this potential problem also exists in the FSF HEAD
sources.

My fix was this:
--- subsegs.c-orig      2006-04-27 13:44:49.893500000 +0000
+++ subsegs.c   2006-04-27 13:47:51.909125000 +0000
@@ -297,7 +297,7 @@ subseg_set_rest (segT seg, subsegT subse
       {
        segment_info_type *seginfo;
        seginfo = seg_info (seg);
-       if (seginfo && seginfo->frchainP == frcP)
+       if (seginfo && (!seginfo->frchainP || seginfo->frchainP ==
frcP))
          seginfo->frchainP = newP;
       }
 #endif

Which I have tested with check-{binutils,gas,gcc} and works well.  So
I'm looking for comments about the approach.  Then I will make up a
patch for HEAD and test there.

Also, JimW suggested a different approach which might be better:
*** tc-arm.c.orig       2004-11-16 22:41:34.000000000 -0800
--- tc-arm.c    2006-04-27 16:22:43.664683290 -0700
*************** md_begin ()
*** 12073,12079 ****
--- 12073,12082 ----
      asection * arm_arch;
      const char * arch_string;
  
+ #if 0
      arm_arch = bfd_make_section_old_way (stdoutput, ARM_NOTE_SECTION);
+ #endif
+     arm_arch = subseg_new (ARM_NOTE_SECTION, 0);
  
  #ifdef OBJ_COFF
      bfd_set_section_flags (stdoutput, arm_arch,
*************** md_begin ()
*** 12084,12090 ****
--- 12087,12095 ----
                           SEC_READONLY | SEC_HAS_CONTENTS);
  #endif
      arm_arch->output_section = arm_arch;
+ #if 0
      subseg_set (arm_arch, 0);
+ #endif
  
      switch (mach)
        {

-- 
Jim Lemke   jwlemke@wasabisystems.com   Orillia, Ontario

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

[James E Wilson]

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

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

[Alan Modra]

On Fri, Apr 28, 2006 at 09:52:46AM -0400, James Lemke wrote:
> --- subsegs.c-orig      2006-04-27 13:44:49.893500000 +0000
> +++ subsegs.c   2006-04-27 13:47:51.909125000 +0000
> @@ -297,7 +297,7 @@ subseg_set_rest (segT seg, subsegT subse
>        {
>         segment_info_type *seginfo;
>         seginfo = seg_info (seg);
> -       if (seginfo && seginfo->frchainP == frcP)
> +       if (seginfo && (!seginfo->frchainP || seginfo->frchainP ==
> frcP))
>           seginfo->frchainP = newP;
>        }
>  #endif

Looks good to me.  Applying to mainline and 2.17.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre