The current git kernel doesn't build with gold: markus@x4 tmp % ld -v GNU gold (GNU Binutils 2.24.51.20140401) 1.11 markus@x4 tmp % cat vdso.lds SECTIONS { .text : { *(.text*) } :text =0x90909090 /DISCARD/ : { *(.discard) *(.discard.*) } } markus@x4 tmp % ld -T vdso.lds ld: error: vdso.lds:4:12: syntax error, unexpected ':' ld: fatal error: unable to parse script file vdso.lds markus@x4 tmp % ld.bfd -T vdso.lds ld.bfd: no input files markus@x4 tmp %
You need a semicolon after the fill constant: .text : { *(.text*) } :text =0x90909090; /DISCARD/ : { Otherwise, gold attempts to parse the fill spec as an expression: "0x90909090 / DISCARD ...".
Are you sure? % ld -T vdso.lds ld: error: vdso.lds:3:41: syntax error, unexpected ';' ld: fatal error: unable to parse script file vdso.lds
(In reply to Markus Trippelsdorf from comment #2) > Are you sure? > > % ld -T vdso.lds > ld: error: vdso.lds:3:41: syntax error, unexpected ';' > ld: fatal error: unable to parse script file vdso.lds Sorry, my mistake. It needs a comma, not a semicolon.
Huh? I agree that your suggestion appears to work, but isn't gold supposed to speak linker script language as spoken by GNU ld? The de facto reference (https://sourceware.org/binutils/docs/ld/Output-Section-Description.html#Output-Section-Description) says: section [address] [(type)] : [AT(lma)] [ALIGN(section_align) | ALIGN_WITH_INPUT] [SUBALIGN(subsection_align)] [constraint] { output-section-command output-section-command ... } [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp] The comma at the end is conspicuously absent. Please either document or fix this. I realize that GNU ld is doing something very strange with fillexp, but the fact that a single comma (but not two commas!) is legal at the end of an output section description appears to be completely undocumented.
This is probably a separate issue, but adding the comma causes: ld.gold: internal error in segment_precedes, at layout.cc:3037
> This is probably a separate issue, but adding the comma causes: > > ld.gold: internal error in segment_precedes, at layout.cc:3037 Yes, that was PR 15355. It's fixed in binutils-2.24. It was probably caused by having two segments in the PHDRS clause with the same type and flags -- what I've seen before is two PT_NULL segments for vvar_sect and hpet_sect: vvar_sect PT_NULL FLAGS(4); /* PF_R */ hpet_sect PT_NULL FLAGS(4); /* PF_R */ Ideally, instead of using PT_NULL for these segments, you could allocate two new GNU-specific segment types. I think that would have benefits elsewhere, where you can look for these segments by type instead of having to infer which segment is which. -cary
(In reply to Cary Coutant from comment #6) > > This is probably a separate issue, but adding the comma causes: > > > > ld.gold: internal error in segment_precedes, at layout.cc:3037 > > Yes, that was PR 15355. It's fixed in binutils-2.24. > > It was probably caused by having two segments in the PHDRS clause with > the same type and flags -- what I've seen before is two PT_NULL > segments for vvar_sect and hpet_sect: > > vvar_sect PT_NULL FLAGS(4); /* PF_R */ > hpet_sect PT_NULL FLAGS(4); /* PF_R */ > > Ideally, instead of using PT_NULL for these segments, you could > allocate two new GNU-specific segment types. I think that would have > benefits elsewhere, where you can look for these segments by type > instead of having to infer which segment is which. > In this case I'm planning on just removing the segments entirely. They don't seem to serve any real purpose.
> Huh? I agree that your suggestion appears to work, but isn't gold supposed to > speak linker script language as spoken by GNU ld? We try to get as close as possible, but the two linkers are enough different that we can't do bug-for-bug compatibility. > The de facto reference > (https://sourceware.org/binutils/docs/ld/Output-Section-Description.html#Output-Section-Description) > says: > > section [address] [(type)] : > [AT(lma)] > [ALIGN(section_align) | ALIGN_WITH_INPUT] > [SUBALIGN(subsection_align)] > [constraint] > { > output-section-command > output-section-command > ... > } [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp] > > The comma at the end is conspicuously absent. Huh. You're right, the docs don't say anything about commas, even though the linker supports it. I'll see about adding it to the docs. > Please either document or fix this. I realize that GNU ld is doing something > very strange with fillexp, but the fact that a single comma (but not two > commas!) is legal at the end of an output section description appears to be > completely undocumented. Another, documented, way of disambiguating your script is to use quotes around the special section name "/DISCARD/". In "Output Section Name", it says: "A section name may consist of any sequence of characters, but a name which contains any unusual characters such as commas must be quoted." I guess they don't think '/' is unusual in a name. -cary
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via abc9061b5c4d684da66945a9928d54a424cb6e4e (commit) from 2cf200a4c8a850e6f696e572ea03f340eae97c8a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=abc9061b5c4d684da66945a9928d54a424cb6e4e commit abc9061b5c4d684da66945a9928d54a424cb6e4e Author: Cary Coutant <ccoutant@google.com> Date: Fri Apr 4 09:28:23 2014 -0700 Document optional comma in linker script. The linker script documentation does not mention the optional comma that may follow an output section command or an overlay command. In some cases, where a fill expression is used, and the next output section command begins with an operator (e.g., "/DISCARD/"), the comma may be required to separate the two commands. Currently, GNU ld doesn't require the comma, but gold does. ld/ PR gold/16804 * ld.texinfo: Document optional comma following output section command and overlay command. ----------------------------------------------------------------------- Summary of changes: ld/ChangeLog | 6 ++++++ ld/ld.texinfo | 9 +++++++-- 2 files changed, 13 insertions(+), 2 deletions(-)
Closing as per comment #8. GNU ld script syntax is ambiguous in places, requiring back-tracking. Is that expression you have for fill 0x90909090 / DISCARD / <missing operand>, or is it just 0x90909090?