Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LLD] EXCLUDE_FILE linker script directive is not excluding files in linker script rule-matching #100109

Open
partaror opened this issue Jul 23, 2024 · 3 comments
Labels

Comments

@partaror
Copy link
Contributor

EXCLUDE_FILE linker script directive is not excluding files in linker script rule-matching.

Reproducible example:

#!/usr/bin/env bash

cat >1.c <<\EOF
int foo() { return 1; }
EOF

cat >2.c <<\EOF
int bar() { return 3; }
EOF

cat >script.t <<\EOF
SECTIONS {
  FOO : { EXCLUDE_FILE(2.o) *(*.text*) }
  BAR : { *(*.text*) }
}
EOF

clang-15 -o 1.o 1.c -c
clang-15 -o 2.o 2.c -c
ld.lld -o a.lld.out 1.o 2.o -T script.t 
ld.bfd -o a.bfd.out 1.o 2.o -T script.t 

Ideally, 1.o(.text) should match FOO output section and 2.o(.text) should match BAR output section. However, when LLD is used, both 1.o(.text) and 2.o(.text) incorrectly matches FOO output section.

Rule-matching is correct when GNU LD is used. (1.o(.text) matches FOO and 2.o(.text) matches BAR)

@partaror partaror changed the title EXCLUDE_FILE linker script directive is not excluding files in linker script rule-matching [LLD] EXCLUDE_FILE linker script directive is not excluding files in linker script rule-matching Jul 23, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Jul 23, 2024

@llvm/issue-subscribers-lld-elf

Author: Parth Arora (partaror)

`EXCLUDE_FILE` linker script directive is not excluding files in linker script rule-matching.

Reproducible example:

#!/usr/bin/env bash

cat &gt;1.c &lt;&lt;\EOF
int foo() { return 1; }
EOF

cat &gt;2.c &lt;&lt;\EOF
int bar() { return 3; }
EOF

cat &gt;script.t &lt;&lt;\EOF
SECTIONS {
  FOO : { EXCLUDE_FILE(2.o) *(*.text*) }
  BAR : { *(*.text*) }
}
EOF

clang-15 -o 1.o 1.c -c
clang-15 -o 2.o 2.c -c
ld.lld -o a.lld.out 1.o 2.o -T script.t 
ld.bfd -o a.bfd.out 1.o 2.o -T script.t 

Ideally, 1.o(.text) should match FOO output section and 2.o(.text) should match BAR output section. However, when LLD is used, both 1.o(.text) and 2.o(.text) incorrectly matches FOO output section.

Rule-matching is correct when GNU LD is used. (1.o(.text) matches FOO and 2.o(.text) matches BAR)

@smithp35
Copy link
Collaborator

I've not checked the source code to confirm. This is a drive by comment just in case you are able to update your script. It does seem like all the existing LLD test cases use the EXCLUDE_FILE inside the section list. For example if you rewrite

SECTIONS {
  FOO : { *(EXCLUDE_FILE(2.o) *.text*) }
  BAR : { *(*.text) }
}

Then this will work:

              60               60        b    16 FOO
              60               60        b    16         1.o:(.text)
              60               60        b     1                 foo
              70               70        b    16 BAR
              70               70        b    16         2.o:(.text)
              70               70        b     1                 bar

It may be that LLD isn't correctly implementing the EXCLUDE_FILE before pattern form.

@partaror
Copy link
Contributor Author

partaror commented Jul 23, 2024

Hi @smithp35,

Thank you for the quick reply. Yes, using EXCLUDE_FILE inside the section patterns list works as expected.

In some cases, it is useful to place EXCLUDE_FILE outside the section patterns list. One example where this is beneficial is described below:

EXCLUDE_FILE(2.o) *(.text.foo .text.bar .text.baz)
*(EXCLUDE_FILE(2.o) .text.foo EXCLUDE_FILE(2.o) .text.bar EXCLUDE_FILE(2.o) .text.baz)

The above two input section descriptions have the same behavior; however, it is much simpler to maintain the input section description with EXCLUDE_FILE outside the section patterns list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants