PATCH: PR 445: A64 linker complains short data segment overflowed

[James E Wilson]

On Wed, 2004-10-13 at 15:32, H. J. Lu wrote:
> 	PR 445
> 	* emulparams/elf64_ia64.sh (SMALL_DATA_CTOR): Set.
> 	(SMALL_DATA_DTOR): Set
> 	* scripttempl/elf.sc: If SMALL_DATA_CTOR is set, move .ctors
> 	after .data. If SMALL_DATA_DTOR is set, move .dtors after .data.

The bug report doesn't clearly say what is wrong.  I had to look at
binutils sources and gcc output to figure out what you were trying to
say.  The problem here is that icc sets the SHF_IA_64_SHORT bit on the
ctor/dtor sections, which it shouldn't, and this causes trouble for the
gp calculation because ctor/dtor are now before the data section, and gp
can't span the entire data section.

The readelf output is ambiguous here, as "p" simply means that some
processor specific section header flag is set, and there is more than
one of them.  The objdump output would have been more useful, as objdump
will print SHORT_DATA when the SHF_IA_64_SHORT bit is set.

So icc needs to be fixed, but even if it is fixed, we probably need to
accept libraries/object files compiled with old icc indefinitely, so the
patch seems reasonable.

I think the patch does have one flaw though.  There is no comment
explaining why we are doing this.  There should be a comment in the
elf64_ia64.sh file saying this is necessary because some icc versions
set the short data flag on ctor/dtor sections.  Even better if we can
list the version number when it was fixed.  Otherwise, people looking at
this in the future won't be able to understand why this weirdness is
there.

The patch is OK with a comment added.

By the way, the FreeBSD elf64_ia64_fbsd.sh file includes elf64_ia64.sh. 
If the Intel compiler does not and will not support FreeBSD, then
perhaps we should clear SMALL_DATA_{CTOR,DTOR} in this file.  It isn't
clear to me if this makes enough difference to matter though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com