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?