* intermittent 0-length for .note.gnu.arm.ident @ 2006-04-20 1:47 James Lemke 2006-04-20 14:40 ` Nick Clifton 2006-04-28 18:41 ` James Lemke 0 siblings, 2 replies; 5+ messages in thread From: James Lemke @ 2006-04-20 1:47 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: intermittent 0-length for .note.gnu.arm.ident 2006-04-20 1:47 intermittent 0-length for .note.gnu.arm.ident James Lemke @ 2006-04-20 14:40 ` Nick Clifton 2006-04-28 18:41 ` James Lemke 1 sibling, 0 replies; 5+ messages in thread From: Nick Clifton @ 2006-04-20 14:40 UTC (permalink / raw) To: James Lemke; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: intermittent 0-length for .note.gnu.arm.ident 2006-04-20 1:47 intermittent 0-length for .note.gnu.arm.ident James Lemke 2006-04-20 14:40 ` Nick Clifton @ 2006-04-28 18:41 ` James Lemke 2006-04-29 14:51 ` James E Wilson 2006-05-01 5:35 ` Alan Modra 1 sibling, 2 replies; 5+ messages in thread From: James Lemke @ 2006-04-28 18:41 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: intermittent 0-length for .note.gnu.arm.ident 2006-04-28 18:41 ` James Lemke @ 2006-04-29 14:51 ` James E Wilson 2006-05-01 5:35 ` Alan Modra 1 sibling, 0 replies; 5+ messages in thread From: James E Wilson @ 2006-04-29 14:51 UTC (permalink / raw) To: James Lemke; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: intermittent 0-length for .note.gnu.arm.ident 2006-04-28 18:41 ` James Lemke 2006-04-29 14:51 ` James E Wilson @ 2006-05-01 5:35 ` Alan Modra 1 sibling, 0 replies; 5+ messages in thread From: Alan Modra @ 2006-05-01 5:35 UTC (permalink / raw) To: James Lemke; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-05-01 5:35 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-20 1:47 intermittent 0-length for .note.gnu.arm.ident James Lemke 2006-04-20 14:40 ` Nick Clifton 2006-04-28 18:41 ` James Lemke 2006-04-29 14:51 ` James E Wilson 2006-05-01 5:35 ` Alan Modra
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).