/xxx/gnu/binutils-2.15.90/objdir/binutils/size -A tmpdir/bintest.o Executing on host: /xxx/gnu/binutils-2.15.90/objdir/binutils/size -A tmpdir/bin test.o (timeout = 300) tmpdir/bintest.o : section size addr $TEXT$ 0 0 $CODE$ 8 0 $LIT$ 0 0 $MILLICODE$ 0 0 $PRIVATE$ 8 0 $DATA$ 8 0 $BSS$ 0 0 Total 24 The value for $TEXT$ should be 8. I don't know about the total as $CODE$ overlays $TEXT$ and $DATA$ overlays $PRIVATE$. Thus, I think the total should be 16. However, previous versions returned 8 for $TEXT$ and a Total of 32. This testsuite failure was introduced by the following change: 2004-06-24 Alan Modra <amodra@bigpond.net.au> * section.c (struct sec): Rename "_cooked_size" to "size". Rename "_raw_size" to "rawsize". (STD_SECTION): Adjust comments. (bfd_set_section_size, bfd_get_section_contents): Use size. (bfd_malloc_and_get_section): New function. ...
Hi, This bug does not appear to be reproducbile with today's binutils sources from the CVS repository. Please could you check and see if you can still make it happen ? Cheers Nick
Subject: Re: FAIL: size -A > This bug does not appear to be reproducbile with today's binutils sources > from > the CVS repository. Please could you check and see if you can still make it > happen ? I just updated and rechecked. I still see the problem: Executing on host: /xxx/gnu/binutils-2.15.90/objdir/binutils/size -A tmpdir/bin test.o (timeout = 300) tmpdir/bintest.o : section size addr $TEXT$ 0 0 $CODE$ 8 0 $LIT$ 0 0 $MILLICODE$ 0 0 $PRIVATE$ 8 0 $DATA$ 8 0 $BSS$ 0 0 Total 24 tmpdir/bintest.o : section size addr $TEXT$ 0 0 $CODE$ 8 0 $LIT$ 0 0 $MILLICODE$ 0 0 $PRIVATE$ 8 0 $DATA$ 8 0 $BSS$ 0 0 Total 24 FAIL: size -A === binutils Summary === # of expected passes 21 # of unexpected failures 1 # of expected failures 1 # of untested testcases 4 I'm building with gcc 3.4.0. I used the following build script: #!/bin/sh export PATH=/opt/gnu/gcc/gcc-3.4.0/bin:/opt/gnu/bin:/opt/perl5/bin:/usr/bin:/usr/sbin:/sbin export CC=gcc CFLAGS="-g -O2" export CXX=g++ CXXFLAGS="-g -O2" ../src/configure --build=hppa2.0w-hp-hpux11.11 --host=hppa2.0w-hp-hpux11.11 --prefix=/opt/gnu --disable-nls && make && make -k check I determined the patch that caused the regression by before and after testing. I'm at OLS this week and don't have much time to look into this in more detail until next week. Dave
Subject: Re: FAIL: size -A Hi Dave, > I just updated and rechecked. I still see the problem: Darn - I cannot reproduce it, but I am using a hpux11.00 system. (I do not have access to an hpux11.11 system). Are you able to investigate any further yourself ? For example is it the size program that is producing bogus output, or is it the bintest.o object file that is corrupt ? (objdump -h tmpdir/bintest.o should tell you). Cheers Nick
Subject: Re: FAIL: size -A > Darn - I cannot reproduce it, but I am using a hpux11.00 system. (I do > not have access to an hpux11.11 system). I also see this on 11.00. Which compiler did you use? > Are you able to investigate any further yourself ? For example is it > the size program that is producing bogus output, or is it the bintest.o > object file that is corrupt ? (objdump -h tmpdir/bintest.o should tell > you). -bash-2.05b$ objdump -h bintest.o bintest.o: file format som Sections: Idx Name Size VMA LMA File off Algn 0 $TEXT$ 00000008 00000000 00000000 000001ec 2**3 1 $CODE$ 00000008 00000000 00000000 000001ec 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 2 $LIT$ 00000000 00000000 00000000 000001f4 2**3 ALLOC, LOAD, READONLY, CODE 3 $MILLICODE$ 00000000 00000000 00000000 000001f4 2**3 ALLOC, LOAD, READONLY, CODE 4 $PRIVATE$ 00000008 00000000 00000000 000001f4 2**3 5 $DATA$ 00000008 00000000 00000000 000001f4 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 6 $BSS$ 00000000 00000000 00000000 00000000 2**3 ALLOC odump -all bintest.o ... Space dictionary for bintest.o: Ind LDPIT Sort Space Subspaces Ldr Fixups Init Ptrs Name 0 LD... 8 0 0 3 -1 0 -1 0 $TEXT$ 1 LDP.. 16 1 3 2 -1 0 -1 0 $PRIVATE$ Subspace dictionary for bintest.o: Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name 0 0 2c ...L0.O.... 24 000001ec 000008 00000000 000008 8 0 3 $CODE$ 1 0 2c ...L0...... 16 000001f4 000000 00000000 000000 8 3 0 $LIT$ 2 0 2c ...L0...... 8 000001f4 000000 00000000 000000 8 3 0 $MILLICODE$ 3 1 1f ...L1...... 24 000001f4 000008 00000000 000008 8 3 1 $DATA$ 4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$ I believe bintest.o is ok. Dave
Subject: Re: FAIL: size -A Hi Dave, Can you send me a copy of your bintest.o object file and size executables ? Cheers Nick
Subject: Re: FAIL: size -A > Subject: Re: FAIL: size -A > > Hi Dave, > > Can you send me a copy of your bintest.o object file and size > executables ? These are the hpux 11.00 versions that I built this morning. Dave
Created attachment 138 [details] size
Created attachment 139 [details] bintest.o
Subject: Re: FAIL: size -A Hi Dave, > These are the hpux 11.00 versions that I built this morning. Thanks - this version of the size program definitely does show the problem, both with the bintest.o file you included and the bintest.o file in my own build directory. Similarly I can definitely report that the size program I built does correctly report the sizes of both bintest.o object files. I am starting to suspect a host compiler bug. I built my version of the size program from yesterdays binutils sources using an old version of gcc: gcc (GCC) 3.2-gnupro-03r1-3 (This is the RedHat supported version of an HPUX native gcc that we sell to various customers). I tried using the native cc compiler but did not get very far. Which compiler are you using ? Cheers Nick
Subject: Re: FAIL: size -A > I am starting to suspect a host compiler bug. I built my version of the > size program from yesterdays binutils sources using an old version of gcc: > > gcc (GCC) 3.2-gnupro-03r1-3 > > (This is the RedHat supported version of an HPUX native gcc that we sell > to various customers). > > I tried using the native cc compiler but did not get very far. > > Which compiler are you using ? The report was with gcc (GCC) 3.4.0. I tried 3.3.3, 3.5.0 20040610, and HP "cc -Ae", all with the same result. I also tried 3.5.0 at -O0. All the compiler builds that I have installed have had a full bootstrap and check prior to installation. Given that the problem occurs both with GCC and HP cc, it seems unlikely that this is a host compiler bug. I don't know much about 3.2-gnupro-03r1-3 but I do know the main cvs versions contain a substantial number of fixes relative to 3.2. The 3.3 branch is currently the main build compiler for the debian and gentoo parisc-linux ports, so it has received quite a bit of real-world testing. Dave
Subject: Re: FAIL: size -A Hi Dave, >>Which compiler are you using ? > The report was with gcc (GCC) 3.4.0. I tried 3.3.3, 3.5.0 20040610, > and HP "cc -Ae", all with the same result. I also tried 3.5.0 at > -O0. > > All the compiler builds that I have installed have had a full bootstrap > and check prior to installation. Given that the problem occurs both with > GCC and HP cc, it seems unlikely that this is a host compiler bug. > > I don't know much about 3.2-gnupro-03r1-3 but I do know the main cvs > versions contain a substantial number of fixes relative to 3.2. The > 3.3 branch is currently the main build compiler for the debian and > gentoo parisc-linux ports, so it has received quite a bit of real-world > testing. OK then, lets assume that it is a binutils bug which for some reason is not being exposed by the gcc 3.2 based compiler I am using. Unfortunately this means that I am not going to be able to debug the problem myself. I could send you the *.o files from my bfd and binutils directories. Maybe these could allow you to verify that a) they build a working 'size' program and b) isolate which file(s) are broken ? Cheers Nick PS. Just a shot in the dark here: if you try recompiling the bfd and binutils sources with -fno-unit-at-a-time does the problem go away ?
Subject: Re: FAIL: size -A > OK then, lets assume that it is a binutils bug which for some reason is > not being exposed by the gcc 3.2 based compiler I am using. > Unfortunately this means that I am not going to be able to debug the > problem myself. I looked at the problem a bit last night. It's definitely a binutils bug specific to SOM. I'm not sure why Allan's change triggered the bug yet but the principal bug is clear. Possibly, it affected the presence of $LIT$ and $MILLICODE$. The size of the space $TEXT$ is calculated at line 2116 in som.c. This calculation assumes that the subspace start address for the subspace with the largest file_loc_init_value is valid. This may be true with the HP assembler but it's not true with gas. Subspace dictionary for bintest.o: Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name 0 0 2c ...L0.O.... 24 000001ec 000008 00000000 000008 8 0 3 $CODE$ 1 0 2c ...L0...... 16 000001f4 000000 00000000 000000 8 3 0 $LIT$ 2 0 2c ...L0...... 8 000001f4 000000 00000000 000000 8 3 0 $MILLICODE$ 3 1 1f ...L1...... 24 000001f4 000008 00000000 000008 8 3 1 $DATA$ 4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$ You can see that the start addresses for all subspaces are zero. There is something a bit strange about $DATA$. I'm not sure why it doesn't start at 0x40000000. When the code loops through choosing save_subspace, it picks $LIT$. So, the size calculated by space_asect->size = (save_subspace.subspace_start - space_asect->vma + save_subspace.subspace_length); is 0 - 0 + 0 = 0. The test would pass if $LIT$ and $MILLICODE$ didn't appear. However, the code is still broken for .o files because we are not calculating subspace_start. The HP documentation indicates that this field is used to ensure subspaces don't overlap. However, I think the linker usually ignores it and computes its own values. In relocatable objects, possibly we should just add up the sizes of the individual subspaces in each space. This ignores the alignment and sort order of the subspaces. On the otherhand, the hpux version of size just lists nonzero subspaces and doesn't attempt to compute the size of each space: -bash-2.05b$ size -v -x tmpdir/bintest.o Subspace Size Physical Address Virtual Address $CODE$ 0x00000008 0x000001ec 0x00000000 $DATA$ 0x00000008 0x000001f4 0x00000000 Total 0x00000010 Dave
Subject: Re: FAIL: size -A Hi Dave, Hi Alan, > Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name > > 0 0 2c ...L0.O.... 24 000001ec 000008 00000000 000008 8 0 3 $CODE$ > 1 0 2c ...L0...... 16 000001f4 000000 00000000 000000 8 3 0 $LIT$ > 2 0 2c ...L0...... 8 000001f4 000000 00000000 000000 8 3 0 $MILLICODE$ > 3 1 1f ...L1...... 24 000001f4 000008 00000000 000008 8 3 1 $DATA$ > 4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$ > > You can see that the start addresses for all subspaces are zero. There > is something a bit strange about $DATA$. I'm not sure why it doesn't > start at 0x40000000. When the code loops through choosing save_subspace, > it picks $LIT$. So, the size calculated by > > space_asect->size = (save_subspace.subspace_start > - space_asect->vma > + save_subspace.subspace_length); > > is 0 - 0 + 0 = 0. The test would pass if $LIT$ and $MILLICODE$ didn't > appear. However, the code is still broken for .o files because we are > not calculating subspace_start. The HP documentation indicates that > this field is used to ensure subspaces don't overlap. However, I think > the linker usually ignores it and computes its own values. > > In relocatable objects, possibly we should just add up the sizes of the > individual subspaces in each space. This ignores the alignment and > sort order of the subspaces. Something like this ? Cheers Nick Index: bfd/som.c =================================================================== RCS file: /cvs/src/src/bfd/som.c,v retrieving revision 1.46 diff -c -3 -p -r1.46 som.c *** bfd/som.c 21 Jul 2004 15:42:57 -0000 1.46 --- bfd/som.c 27 Jul 2004 11:15:27 -0000 *************** setup_sections (abfd, file_hdr, current_ *** 1913,1918 **** --- 1913,1919 ---- struct som_subspace_dictionary_record subspace, save_subspace; unsigned int subspace_index; asection *space_asect; + bfd_size_type space_size = 0; char *newname; /* Read the space dictionary element. */ *************** setup_sections (abfd, file_hdr, current_ *** 2104,2109 **** --- 2105,2114 ---- subspace_asect->alignment_power = exact_log2 (subspace.alignment); if (subspace_asect->alignment_power == (unsigned) -1) goto error_return; + + /* Keep track of the accumulated sizes of the sections. + This ignores alignment and ordering issues... */ + space_size += save_subspace.subspace_length; } /* This can happen for a .o which defines symbols in otherwise *************** setup_sections (abfd, file_hdr, current_ *** 2111,2121 **** if (!save_subspace.file_loc_init_value) space_asect->size = 0; else ! /* Setup the size for the space section based upon the info in the ! last subspace of the space. */ ! space_asect->size = (save_subspace.subspace_start ! - space_asect->vma ! + save_subspace.subspace_length); } /* Now that we've read in all the subspace records, we need to assign a target index to each subspace. */ --- 2116,2135 ---- if (!save_subspace.file_loc_init_value) space_asect->size = 0; else ! { ! #if 0 ! /* Setup the size for the space section based upon the info in the ! last subspace of the space. */ ! space_asect->size = (save_subspace.subspace_start ! - space_asect->vma ! + save_subspace.subspace_length); ! #else ! /* The subspace_start field is not initialised, so it cannot ! be used for length calculations. Instead we use the ! space_size value which we have been accumulating. */ ! space_asect->size = space_size; ! #endif ! } } /* Now that we've read in all the subspace records, we need to assign a target index to each subspace. */
Subject: Re: FAIL: size -A > Something like this ? > + space_size += save_subspace.subspace_length; ^ subspace > --- 2116,2135 ---- > if (!save_subspace.file_loc_init_value) > space_asect->size = 0; > else > ! { > ! #if 0 > ! /* Setup the size for the space section based upon the info in the > ! last subspace of the space. */ > ! space_asect->size = (save_subspace.subspace_start > ! - space_asect->vma > ! + save_subspace.subspace_length); I came to the conclusion that we should retain the old code when the object isn't relocatable only. I tweaked the patch a bit. It fixes the regression and has no new fails. I'm wondering if spaces should included in the total. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Index: som.c =================================================================== RCS file: /cvs/src/src/bfd/som.c,v retrieving revision 1.46 diff -u -3 -p -r1.46 som.c --- som.c 21 Jul 2004 15:42:57 -0000 1.46 +++ som.c 28 Jul 2004 03:10:03 -0000 @@ -1913,6 +1913,7 @@ setup_sections (abfd, file_hdr, current_ struct som_subspace_dictionary_record subspace, save_subspace; unsigned int subspace_index; asection *space_asect; + bfd_size_type space_size = 0; char *newname; /* Read the space dictionary element. */ @@ -2104,6 +2105,9 @@ setup_sections (abfd, file_hdr, current_ subspace_asect->alignment_power = exact_log2 (subspace.alignment); if (subspace_asect->alignment_power == (unsigned) -1) goto error_return; + + /* Keep track of the accumulated sizes of the sections. */ + space_size += subspace.subspace_length; } /* This can happen for a .o which defines symbols in otherwise @@ -2111,11 +2115,25 @@ setup_sections (abfd, file_hdr, current_ if (!save_subspace.file_loc_init_value) space_asect->size = 0; else - /* Setup the size for the space section based upon the info in the - last subspace of the space. */ - space_asect->size = (save_subspace.subspace_start - - space_asect->vma - + save_subspace.subspace_length); + { + if (file_hdr->a_magic != RELOC_MAGIC) + { + /* Setup the size for the space section based upon the info + in the last subspace of the space. */ + space_asect->size = (save_subspace.subspace_start + - space_asect->vma + + save_subspace.subspace_length); + } + else + { + /* The subspace_start field is not initialised in relocatable + only objects, so it cannot be used for length calculations. + Instead we use the space_size value which we have been + accumulating. This isn't an accurate estimate since it + ignores alignment and ordering issues. */ + space_asect->size = space_size; + } + } } /* Now that we've read in all the subspace records, we need to assign a target index to each subspace. */
Subject: Re: FAIL: size -A Hi Dave, > I came to the conclusion that we should retain the old code when the > object isn't relocatable only. I tweaked the patch a bit. It fixes > the regression and has no new fails. Great - please consider this patch approved and check it in at your leisure. > I'm wondering if spaces should included in the total. For relocatable objects ? Presumably computing a size that is too big is preferable to one one that is too small, (with the assumption that the correct size will be computed when the final link is performed), so I would think that allowing extra space for possible alignment would be a good idea. Cheers Nick
Subject: Re: FAIL: size -A > > I'm wondering if spaces should included in the total. > > For relocatable objects ? Presumably computing a size that is too big > is preferable to one one that is too small, (with the assumption that > the correct size will be computed when the final link is performed), so > I would think that allowing extra space for possible alignment would be > a good idea. That's reasonable. However, I was concerned about a different issue. Here is the current output for size -A with bintest.o: -bash-2.05b$ ./size -A tmpdir/bintest.o tmpdir/bintest.o : section size addr $TEXT$ 8 0 $CODE$ 8 0 $LIT$ 0 0 $MILLICODE$ 0 0 $PRIVATE$ 8 0 $DATA$ 8 0 $BSS$ 0 0 Total 32 The problem with the total is that we are double counting. The $CODE$, $LIT$ and $MILLICODE$ subspace make up the space $TEXT$. $DATA$ and $BSS$ make up the space $PRIVATE$. Here are the details: Space dictionary for tmpdir/bintest.o: Ind LDPIT Sort Space Subspaces Ldr Fixups Init Ptrs Name 0 LD... 8 0 0 3 -1 0 -1 0 $TEXT$ 1 LDP.. 16 1 3 2 -1 0 -1 0 $PRIVATE$ Subspace dictionary for tmpdir/bintest.o: Sub Sp AC RDCLQIOENKT Key Loc/Init InitLn Start Len Align Fixups Name 0 0 2c ...L0.O.... 24 000001ec 000008 00000000 000008 8 0 3 $CODE$ 1 0 2c ...L0...... 16 000001f4 000000 00000000 000000 8 3 0 $LIT$ 2 0 2c ...L0...... 8 000001f4 000000 00000000 000000 8 3 0 $MILLICODE$ 3 1 1f ...L1...... 24 000001f4 000008 00000000 000008 8 3 1 $DATA$ 4 1 1f ...L1...... 80 00000000 000000 00000000 000000 8 -1 0 $BSS$ The manpage for size shows the following output for -A: $ size --format=SysV ranlib size ranlib : section size addr .text 294880 8192 .data 81920 303104 .bss 11592 385024 Total 388392 The closest SOM approximation would be: -bash-2.05b$ ./size -A tmpdir/bintest.o tmpdir/bintest.o : section size addr $TEXT$ 8 0 $PRIVATE$-$BSS$ 8 0 $BSS$ 0 0 Total 16 This what we get with -B: -bash-2.05b$ ./size -B tmpdir/bintest.o text data bss dec hex filename 8 8 0 16 10 tmpdir/bintest.o There is one other standard space, $THREAD_SPECIFIC$. It contains the subspace $TBSS$. Of course, users can define their own spaces and subspaces if they want. Dave
Subject: Re: FAIL: size -A Hi Dave, > -bash-2.05b$ ./size -A tmpdir/bintest.o > tmpdir/bintest.o : > section size addr > $TEXT$ 8 0 > $CODE$ 8 0 > $LIT$ 0 0 > $MILLICODE$ 0 0 > $PRIVATE$ 8 0 > $DATA$ 8 0 > $BSS$ 0 0 > Total 32 > > The problem with the total is that we are double counting. The $CODE$, > $LIT$ and $MILLICODE$ subspace make up the space $TEXT$. $DATA$ and > $BSS$ make up the space $PRIVATE$. Here are the details: Hmm - it seems to me that we must either teach the size program about subspaces as a generic thing, or else have a target specific extension to the program which can display sections and sub-spaces specifically for the SOM format. Personally I tend towards the latter as it could be contained in a separate file and only minimally intrudce into the generic size sources. Cheers Nick
Subject: Re: FAIL: size -A > Hmm - it seems to me that we must either teach the size program about > subspaces as a generic thing, or else have a target specific extension > to the program which can display sections and sub-spaces specifically > for the SOM format. Actually, I view subspaces as equivalent to sections. Spaces are just a collection of sections/subspaces lying in the same space/memory region. This reflects the division of the virtual memory space into four quadrants (i.e., spaces). While it possible to have more than one space mapping to any given quadrant, this is rare in practice. On the other hand, numerous subspaces with different attributes and names are common. It's the subspaces that get sorted and merged with the subspaces from other objects in a link. So, I think we could ignore spaces for the purpose of the size program. This is more or less what HP did. At the moment, I don't know how hard this would be to implement. > Personally I tend towards the latter as it could be contained in a > separate file and only minimally intrudce into the generic size sources. Seems reasonable from a design standpoint. Dave
I think we can probably exclude SOM spaces by simply ignoring any BFD section with no flags set. It seems to me that a BFD section without at least one of SEC_ALLOC and SEC_HAS_CONTENTS is quite useless as a real section, so such sections should not occur except in weird cases like SOM spaces.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e19511a60cda301feacdb6244375363b08dccf7d commit e19511a60cda301feacdb6244375363b08dccf7d Author: Alan Modra <amodra@gmail.com> Date: Thu Nov 21 20:44:54 2019 +1030 PR273, SOM size -A The SOM backend creates BFD sections for "spaces", and "sub-spaces". "sub-spaces" are what we normally think of as a section, "spaces" aggregate "sub-spaces". Thus it does not really make sense to include "spaces" for size -A since that would double count total size. It so happens that real sections ought to have at least one of the ALLOC and HAS_CONTENTS flags set, so this patch excludes "spaces" but excluding BFD sections with no flags set. PR 273 * size.c (sysv_internal_sizer, sysv_internal_printer): Exclude sections with no flag bits set. * testsuite/binutils-all/size.exp: Allow $CODE$ as a text section.
Fixed