[Bug ld/12066] New: cannot move location counter backwards (from 00000000000067e0 to 0000000000000000)
Today I tried to compile coreboot and seabios for one of my boards. It failed under Ubuntu so I tried Debian chroot. It compiled fine under Debian so I tried to find out where is a problem. Matthias Klose pointed me at binutils and it was proper hint. Current (2.20.51.20100925-1) version in Debian/experimental had same problem as Ubuntu one (2.20.51.20100908-0ubuntu2). So I fetched few versions from snapshot.debian.org and started testing. Last good version was 2.20.51.20100527-1 - both project compiled without problems. coreboot (svn://coreboot.org/coreboot/tr...@5858) failure: gcc -m32 -Wa,--divide -fno-stack-protector -Wl,--build-id=none -nostdlib -nostartfiles -static -o build/coreboot_ram -Lbuild -T src/arch/i386/coreboot_ram.ld build/coreboot_ram.o src/arch/i386/coreboot_ram.ld:143 cannot move location counter backwards (from 00118000 to 4000) collect2: ld returned 1 exit status make: *** [build/coreboot_ram] Error 1 seabios (94dc9c49c283cd576c25692d17567035557a2505 revision) failure: Linking out/rom16.o ld -T out/romlayout16.lds out/code16.o -o out/rom16.o out/romlayout16.lds:429 cannot move location counter backwards (from 67e0 to ) make: *** [out/rom16.o] Error 1 -- Summary: cannot move location counter backwards (from 67e0 to ) Product: binutils Version: 2.21 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: marcin dot juszkiewicz at linaro dot org CC: bug-binutils at gnu dot org GCC host triplet: x86_64-linux-gnu GCC target triplet: i586-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=12066 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/11997] Different behevior of MEMORY regions
--- Additional Comments From nickc at redhat dot com 2010-09-27 15:41 --- There is a discrepancy between the behaviour of LD and GOLD with regard to unspecified VMA and LMA values for sections mentioned in linker scripts that use memory regions. LD will place any section which does not have an explicit VMA address or an explicit output region into the first region in the MEMORY list that has compatible attributes. (In the testcase being used in the LD and GOLD testsuites this means that sec0 is placed into region2). This is contrary to the documentation which says: Output Section Address The "address" is an expression for the VMA (the virtual memory address) of the output section. If you do not provide "address", the linker will set it based on "region" if present, or otherwise based on the current value of the location counter. If the section has an VMA address but does not have an LMA address then LD will again base the LMA on the first compatible memory region, whereas GOLD will just set the LMA to be the same as the VMA. The manual states that: If neither AT nor AT> is specified for an allocatable section, the linker will set the LMA such that the difference between VMA and LMA for the section is the same as the preceding output section in the same region. If there is no preceding output section or the section is not allocatable, the linker will set the LMA equal to the VMA. It does not specify what happens if the section does not have a memory region specified for it. In the testcase sec3 is given an LMA of 0x5000 by GOLD (the same as its VMA) but it is given an LMA of 0x412c by LD. (0x412c comes from subtracting 0xed4 from 0x5000, so that VMA - LMA of sec3 == VMA - LMA of sec1. sec1 is in region2 which is the first viable memory region). I am now working on a patch to: a) update the linker documentation. (On the assumption that LD's behaviour is correct). b) update GOLD to behave in the same way as LD. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11997 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11983] libbfd reuses pointer passed to bfd_openr
--- Additional Comments From carlo at alinoe dot com 2010-09-27 16:18 --- Hi, I'm sorry I still haven't the time to actually test this. So, instead I just looked at the patch :p. It looks good, I'm sure it would solve my problem in the sense that if I tried it it would work. Nevertheless the following remarks: 1) if (x) free(x); seems to make little sense. free(0) works fine. 2) I didn't check if you missed an instance of assignment to the filename member. 3) Some applications (like mine) might already strdup the filename passed to libbfd themselves because of this, so there needs to be some documentation about this (change), still. Can't think of any other remarks that would apply. -- What|Removed |Added Status|WAITING |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=11983 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
