Antoine Jacoutot:
> There's also sysutils/firmware/vmm:
>
> ===> Building for vmm-firmware-1.11.0p0
> The version of LD on this system (ld -nopie -znorelro) does not properly
> handle
> alignments. As a result, this project can not be built.
>From scripts/test-build.sh:
------------------->
# Test if ld's alignment handling is correct. This is a known problem
# with the linker that ships with Ubuntu 11.04.
cat - > $TMPFILE1 <<EOF
const char v1[] __attribute__((section(".text.v1"))) = "0123456789";
const char v2[] __attribute__((section(".text.v2"))) = "0123456789";
EOF
cat - > $TMPFILE1_ld <<EOF
SECTIONS
{
.mysection 0x88f0 : {
. = 0x10 ;
*(.text.v1)
. = 0x20 ;
*(.text.v2)
. = 0x30 ;
}
}
EOF
$CC -O -g -c $TMPFILE1 -o $TMPFILE1o > /dev/null 2>&1
...
$LD -T $TMPFILE1_ld $TMPFILE1o -o $TMPFILE2o > /dev/null 2>&1
...
<-------------------
ld: error: testcompile1.lds:4: unable to move location counter backward for:
.mysection
Does ld.lld treat the location counter assignments as absolute?
ld.bfd handles them as relative to the segment start address:
Hex dump of section '.mysection':
0x000088f0 00000000 00000000 00000000 00000000 ................
0x00008900 00000000 00003938 37363534 33323130 0123456789......
0x00008910 00000000 00003938 37363534 33323130 0123456789......
Since I have lld 7.0.0 at hand on FreeBSD, I checked whether it
fixes this problem, but in fact it adds another error:
ld.lld: error: testcompile1.lds:4: unable to move location counter backward
for: .mysection
ld.lld: error: section .mysection at 0x88F0 of size 0xFFFFFFFFFFFF7740 exceeds
available address space
> The problem may be the result of this LD bug report:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12726
That's for GNU binutils 2.21. And it doesn't look applicable. The
.text.v1 and .text.v2 sections have size 0xb and alignment 1 in the
ELF header.
--
Christian "naddy" Weisgerber na...@mips.inka.de
