Performance of ld on GFS (Global File System)

[Harald Anlauf]

> It's probably this (from the Sun Linker and Libraries manual):
> 
> SHN_AMD64_LCOMMON
> 
>     x64 specific common block label. This label is similar to
> SHN_COMMON, but provides for identifying a large common block.
> 
> 64-bit PA-RISC also has a special section index for huge common, which
> tells the linker to put the common block in something other than .bss
> (perhaps .lbss, but my memory is hazy). Presumably, SHN_AMD64_LCOMMON
> has a similar purpose, and a simple readelf of your successful link
> output might tell us what the right section name is, but I don't know
> if the linker needs to take any additional special actions for symbols
> defined this way.

I am not familiar with using readelf, so I ran "readelf -a" on the objects
and on the a.out files for both "models", see the attached .tar file.

Looking at the differences in the readelf output for the object files,
I find in the symbol table:
19: 0000000000000010     4 OBJECT  GLOBAL DEFAULT  COM mpi_fortran_bottom_
vs.
19: 0000000000000010     4 OBJECT  GLOBAL DEFAULT LARGE_COM mpi_fortran_bottom_

In the linked program I find a section .lbss (model=medium) where
the other has .bss (model=small).

BTW: the linker used in the successful link step is:
GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)
I also get a successful link with a self-compiled:
GNU ld (GNU Binutils) 2.18

Harald

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: suncommon.tar.gz
Type: application/x-gzip
Size: 9649 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20081006/febbafd6/attachment.bin>