Summary: | SOM size -A | ||
---|---|---|---|
Product: | binutils | Reporter: | John David Anglin <danglin> |
Component: | binutils | Assignee: | Alan Modra <amodra> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bug-binutils |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | 2.34 | ||
Host: | hppa2.0w-hp-hpux11.11 | Target: | hppa2.0w-hp-hpux11.11 |
Build: | hppa2.0w-hp-hpux11.11 | Last reconfirmed: | |
Attachments: |
size
bintest.o |
Description
John David Anglin
2004-07-20 02:07:05 UTC
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 |