On Mon, 30 Apr 2007, Michael L. Hitch wrote:

>  The pg_krb_caseins_users symbol comes from libpq/auth.o, and a readelf -s 
> on that file shows:
>
>   Num:    Value  Size Type    Bind   Vis      Ndx Name
>    14: 00000000     4 OBJECT  GLOBAL DEFAULT    4 pg_krb_server_hostname
>    35: 00000004     4 OBJECT  GLOBAL DEFAULT  COM pg_krb_server_keyfile
>    36: 00000004     4 OBJECT  GLOBAL DEFAULT  COM pg_krb_srvnam
>    37: 00000001     1 OBJECT  GLOBAL DEFAULT  COM pg_krb_caseins_users
>
>  If the Value field specifies the alignment requirement, then it looks like 
> gas is generating the proper alighment information, in which case the problem 
> would be with ld not aligning things properly.

   OK, I did a simple little test (two files with the first one having an 
odd common allocation), and it worked as expected.  A link map generate 
with -M even showd a 3 byte filler to align a 4 byte item following a 1 
byte item.

   I then relinked postgres with -M, and noticed the following in the 
common allocations:

  *(.scommon)
  .scommon       0x0000000000888e80        0x4 /usr/lib/crt0.o
                 0x0000000000888e80                environ
  .scommon       0x0000000000888e84        0x5 access/SUBSYS.o
                 0x0000000000888e84                XactIsoLevel
                 0x0000000000888e88                XactReadOnly
  .scommon       0x0000000000888e89       0x1c bootstrap/SUBSYS.o
                 0x0000000000888e89                boot_yychar
...
  .scommon       0x0000000000888ee6       0x11 libpq/SUBSYS.o
                 0x0000000000888ee6                pg_krb_srvnam
                 0x0000000000888eea                Unix_socket_group
                 0x0000000000888eee                pg_krb_server_keyfile
                 0x0000000000888ef2                pg_krb_caseins_users
                 0x0000000000888ef3                Unix_socket_permissions
  .scommon       0x0000000000888ef7        0x4 main/SUBSYS.o
                 0x0000000000888ef7                progname
  .scommon       0x0000000000888efb        0x4 nodes/SUBSYS.o

   Note that it allocated an odd number of bytes for the second object 
file, and did not align the items from the following object file.  Also 
note the same thing when progname was allocated.

   All the object files have been linked into a smaller number of SUBSYS.o 
relocatable object files, so I did a similar thing with my simple test 
case and finally figured out what is going wrong.  The object file 
generated by cc just has the variables as common variables:
     11: 00000001     1 OBJECT  GLOBAL DEFAULT  COM c1
     13: 00000004     2 OBJECT  GLOBAL DEFAULT  COM c2

   When ld is used to link the object file into another relocatable object 
file, it puts the small common variables into the .sbss section (used for 
indexed access via the GP register):
     16: 00000004     2 OBJECT  GLOBAL DEFAULT PRC[0xff03] c2
     17: 00000001     1 OBJECT  GLOBAL DEFAULT PRC[0xff03] c1
and the .sbss section is defined as:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 5] .sbss             NOBITS          00000000 0000c0 000000 00 WAp  0   0  1

   Aha!  That section has an alignment of 1, so when ld links the various 
.sbss sections together, it won't get the proper alignment.


--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA