Test results of memory_test.sh depends on versions of GCC. On Linux/x86, GCC 4.2 and GCC 4.3 failed with [hjl@gnu-6 testsuite]$ cat memory_test.sh.log FAIL: memory_test.sh (exit: 1) ============================== pattern " LOAD 0x00203c 0x0*00004000 0x0*0000603c 0x0000\?2a 0x0000\?2a R E 0x1000" not found in file memory_test.stdout. [hjl@gnu-6 testsuite]$ cat memory_test.stdout There are 13 section headers, starting at offset 0x20e8: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .sec0 PROGBITS 00000000 001000 000002 00 A 0 0 1 [ 2] .sec1 PROGBITS 00001000 00112c 000002 00 A 0 0 1 [ 3] .sec3 PROGBITS 00005000 002000 000002 00 A 0 0 1 [ 4] .sec2 PROGBITS 00004000 00203c 000002 00 A 0 0 1 [ 5] .text PROGBITS 00004004 002040 000000 00 AX 0 0 4 [ 6] .sec4 PROGBITS 00004004 002040 000002 00 A 0 0 1 [ 7] .data PROGBITS 00004008 002044 000000 00 WA 0 0 4 [ 8] .bss NOBITS 00004008 002044 000000 00 WA 0 0 4 [ 9] .note.gnu.gold-version NOTE 00000000 002044 00001c 00 0 0 4 [10] .symtab SYMTAB 00000000 002060 000020 10 11 1 4 [11] .strtab STRTAB 00000000 002080 000006 00 0 0 1 [12] .shstrtab STRTAB 00000000 002086 000061 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Elf file type is EXEC (Executable file) Entry point 0x0 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00002 0x00002 R 0x1000 LOAD 0x00112c 0x00001000 0x0000012c 0x00002 0x00002 R 0x1000 LOAD 0x002000 0x00005000 0x00005000 0x00002 0x00002 R 0x1000 LOAD 0x00203c 0x00004000 0x0000603c 0x00006 0x00006 R E 0x1000 LOAD 0x002044 0x00004008 0x00006044 0x00000 0x00000 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .sec0 01 .sec1 02 .sec3 03 .sec2 .text .sec4 04 .data .bss [hjl@gnu-6 testsuite]$ The same input generates different results with ld: [hjl@gnu-6 tmp]$ ld -m elf_i386 -T /export/gnu/import/git/binutils/gold/testsuite/memory_test.t memory_test.o -z max-page-size=0x1000 ld: a.out: section .sec1 lma 0x12c adjusted to 0x12c [hjl@gnu-6 tmp]$ readelf -Sl a.out There are 9 section headers, starting at offset 0x403c: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .sec0 PROGBITS 00002000 002000 000002 00 A 0 0 1 [ 2] .sec1 PROGBITS 00001000 001000 000002 00 A 0 0 1 [ 3] .sec2 PROGBITS 00004000 004000 000002 00 A 0 0 1 [ 4] .sec3 PROGBITS 00005000 003000 000002 00 A 0 0 1 [ 5] .sec4 PROGBITS 00002002 002002 000002 00 A 0 0 1 [ 6] .shstrtab STRTAB 00000000 004002 000039 00 0 0 1 [ 7] .symtab SYMTAB 00000000 0041a4 000070 10 8 6 4 [ 8] .strtab STRTAB 00000000 004214 000006 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Elf file type is EXEC (Executable file) Entry point 0x2000 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0xfffff12c 0x01002 0x01002 R 0x1000 LOAD 0x002000 0x00002000 0x00002000 0x00004 0x00004 R 0x1000 LOAD 0x003000 0x00005000 0x0000412c 0x00002 0x00002 R 0x1000 LOAD 0x004000 0x00004000 0x0000603c 0x00002 0x00002 R 0x1000 Section to Segment mapping: Segment Sections... 00 .sec1 01 .sec0 .sec4 02 .sec3 03 .sec2 [hjl@gnu-6 tmp]$
Subject: Bug 11997 CVSROOT: /cvs/src Module name: src Changes by: nickc@sourceware.org 2010-09-10 11:50:24 Modified files: gold : ChangeLog gold/testsuite : memory_test.t Log message: PR gold/11997 * testsuite/memory_test.t: Discard any sections that are not needed. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.635&r2=1.636 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/memory_test.t.diff?cvsroot=src&r1=1.1&r2=1.2
Hi H.J. This is related to PR 11985. GOLD insists on creating some sections in the output file which LD does not. It is not related to the MEMORY region code. I have checked in a patch to the memory_test testsuite entry to discard the unneeded sections. With this patch applied both GOLD and LD produce the same output. The underlying problem remains however, so I do not know if you wish to close this PR or not. Cheers Nick
(In reply to comment #2) > Hi H.J. > > This is related to PR 11985. GOLD insists on creating some sections in the > output file which LD does not. It is not related to the MEMORY region code. > > I have checked in a patch to the memory_test testsuite entry to discard the > unneeded sections. With this patch applied both GOLD and LD produce the same > output. > There are 2 problems with the current binutils in CVS: 1. I still got FAIL: memory_test.sh (exit: 1) ============================== pattern " LOAD 0x00203c 0x0*00004000 0x0*0000603c 0x0000\?2a 0x0000\? 2a R E 0x1000" not found in file memory_test.stdout. 2. Gold and ld still generate different outputs.
The memory test failure is fixed. However, there does still seem to be a relevant difference between gold and GNU ld. I used -z max-page-size=0x1000 to eliminate differences due to the page size. With that, gold puts the VMA of the segments at 0, 0x1000, 0x5000, 0x4000, and the LMA at 0, 0x12c, 0x5000, 0x603c. GNU ld puts the VMA at 0, 0x2000, 0x5000, 0x4000 and the LMA at 0, 0x2000, 0x412c, 0x603c. Also gold assigns the sections to segments in the order .sec0, .sec1, .sec3, .sec2, whereas GNU ld generates .sec1, .sec0, .sec3, .sec2. So there seem to be a number of relevant differences.
Created attachment 5040 [details] gold.i11997.patch.2.bz2 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.
Hi Guys, I have applied a patch to bring GOLD's handling of MEMORY regions into line with LD's behaviour. With this patch applied there are still two discrepancies in the output of the two linkers when running the rgn-at5/memory_test testcase. 1. GOLD creates an extra segment to hold the program headers, LD does not. 2. GOLD orders the sections in the section header by file offset, LD orders them by the sequence in which they were declared in the linker script. I do not feel that these are major issues, but I am leaving the PR open in case anyone else feels differently. Cheers Nick PS. I tried to upload the patch to the Issue, but the bugzilla system would not let me. So instead I am attaching it to this email.
> 1. GOLD creates an extra segment to hold the program headers, LD does > not. > > 2. GOLD orders the sections in the section header by file offset, LD > orders them by the sequence in which they were declared in the linker > script. > > I do not feel that these are major issues, but I am leaving the PR open > in case anyone else feels differently. Looks like no one felt differently. Closing.