Bug 273 - FAIL: size -A
Summary: FAIL: size -A
Status: WAITING
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-20 02:07 UTC by John David Anglin
Modified: 2004-07-21 15:11 UTC (History)
2 users (show)

See Also:
Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
Build: hppa2.0w-hp-hpux11.11
Last reconfirmed:


Attachments
size (849.84 KB, application/octet-stream)
2004-07-23 05:22 UTC, dave@hiauly1.hia.nrc.ca
Details
bintest.o (313 bytes, application/octet-stream)
2004-07-23 05:22 UTC, dave@hiauly1.hia.nrc.ca
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2004-07-20 02:07:05 UTC
/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.
...
Comment 1 Nick Clifton 2004-07-21 15:11:39 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
Comment 2 dave@hiauly1.hia.nrc.ca 2004-07-22 03:07:14 UTC
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
Comment 3 Nick Clifton 2004-07-22 11:46:49 UTC
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

Comment 4 dave@hiauly1.hia.nrc.ca 2004-07-22 13:45:44 UTC
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
Comment 5 Nick Clifton 2004-07-22 14:22:54 UTC
Subject: Re:  FAIL: size -A

Hi Dave,

   Can you send me a copy of your bintest.o object file and size 
executables ?

Cheers
   Nick
Comment 6 dave@hiauly1.hia.nrc.ca 2004-07-23 05:22:02 UTC
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
Comment 7 dave@hiauly1.hia.nrc.ca 2004-07-23 05:22:03 UTC
Created attachment 138 [details]
size
Comment 8 dave@hiauly1.hia.nrc.ca 2004-07-23 05:22:03 UTC
Created attachment 139 [details]
bintest.o
Comment 9 Nick Clifton 2004-07-23 12:48:46 UTC
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
Comment 10 dave@hiauly1.hia.nrc.ca 2004-07-23 14:32:59 UTC
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
Comment 11 Nick Clifton 2004-07-26 14:03:20 UTC
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 ?

Comment 12 dave@hiauly1.hia.nrc.ca 2004-07-26 16:30:10 UTC
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
Comment 13 Nick Clifton 2004-07-27 11:28:52 UTC
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.  */
Comment 14 dave@hiauly1.hia.nrc.ca 2004-07-28 03:27:36 UTC
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.  */
Comment 15 Nick Clifton 2004-07-28 09:40:07 UTC
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


Comment 16 dave@hiauly1.hia.nrc.ca 2004-07-28 15:21:43 UTC
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
Comment 17 Nick Clifton 2004-07-29 16:14:57 UTC
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
Comment 18 dave@hiauly1.hia.nrc.ca 2004-07-29 18:57:24 UTC
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