[Bug binutils/273] FAIL: size -A

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2004-07-26 16:30 -------
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


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=273

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.