LLD linker script parser accepts too much in input section wildcard patterns

[mysterymath]

We ran across an instance of strange parser behavior in LLD; it apparently is willing to accept the following as an input section wildcard:

*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.text*)) }

  PROVIDE_HIDDEN(__code_end = .)

There is a missing parenthesis after .text*; there should be three, not two. But LLD doesn't issue a diagnostic; it silently considers the all of the linker script up until the next paren as part of the pattern.

This appears to be considerably more lenient than GNU LD's wildcard pattern:
https://github.com/bminor/binutils-gdb/blob/363baa11378c6383eada19f6bc851fc7230c5dea/ld/ldlex.l#L95

[llvmbot]

@llvm/issue-subscribers-lld-elf

Author: Daniel Thornburgh (mysterymath)

We ran across an instance of strange parser behavior in LLD; it apparently is willing to accept the following as an input section wildcard: ``` *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.text*)) }

PROVIDE_HIDDEN(__code_end = .)

There is a missing parenthesis after `.text*`; there should be three, not two. But LLD doesn't issue a diagnostic; it silently considers the all of the linker script up until the next paren as part of the pattern.

This appears to be considerably more lenient than GNU LD's wildcard pattern:
https://github.com/bminor/binutils-gdb/blob/363baa11378c6383eada19f6bc851fc7230c5dea/ld/ldlex.l#L95
</details>

[llvmbot]

@llvm/issue-subscribers-bug

Author: Daniel Thornburgh (mysterymath)

We ran across an instance of strange parser behavior in LLD; it apparently is willing to accept the following as an input section wildcard: ``` *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.text*)) }

PROVIDE_HIDDEN(__code_end = .)

There is a missing parenthesis after `.text*`; there should be three, not two. But LLD doesn't issue a diagnostic; it silently considers the all of the linker script up until the next paren as part of the pattern.

This appears to be considerably more lenient than GNU LD's wildcard pattern:
https://github.com/bminor/binutils-gdb/blob/363baa11378c6383eada19f6bc851fc7230c5dea/ld/ldlex.l#L95
</details>

[MaskRay]

Thanks for the report. The lexing rule lld uses is quite loose. I added the following test in 2020 (https://reviews.llvm.org/D91180).

#--- lparen.lds
## ( is recognized as a section name pattern. Note, ( is rejected by GNU ld.
# RUN: ld.lld -T %t/lparen.lds %t.o -o %t.out
# RUN: llvm-objdump --section-headers %t.out | FileCheck --check-prefix=SEC-NO %s
SECTIONS {
 .text : { *(.a* ( ) }
}

I'll need to play with the two linkers to figure out how we can improve the status quo.

My gut feeling is that the lexer has to be more context aware (see also ScriptLexer::maybeSplitExpr).

[MaskRay]

Fixed by #84130. As the description says, the non-stateful lexer is not so good. We have quirks with at least:

• unquote
• ScriptLexer::maybeSplitExpr
• accepting certain tokens that GNU ld doesn't

The lexer/parser needs a large rework.