Details: see https://bugs.llvm.org/show_bug.cgi?id=50812
Details
- Reviewers
int3 gkm - Group Reviewers
Restricted Project - Commits
- rGc7c5a1c9ae34: [lld-macho] Ignore debug symbols while preparing relocations.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Added test (with a checked-in .o file, unless someone can tell me a way to produce it within the test :) lld doesn't support -r yet )
(I'm genuinely curious about how these symbols are typically generated)
You can produce it with:
echo "int main() {return 1;}" > test.cc clang -c -g -o test.o test.c ld -r -o test2.o test.o; ld64.lld.darwinnew -platform_version macos 11.3 11.0 -arch x86_64 test2.o
Ah, ld -r... that bit us before in D104502: [lld-macho] Handle non-extern symbols marked as private extern :)
with a checked-in .o file, unless someone can tell me a way to produce it within the test
Let's use yaml2obj instead. Other LLVM tool tests use raw .o files sometimes, but I get the sense that it's a legacy decision and people are pushing back on further additions.
As a bonus, you can inline the YAML within the test file via split-file --no-leading-lines, see e.g. dylink-ordinal.s.
lld/test/MachO/bug_50812.s | ||
---|---|---|
6 | you're missing a RUN: here (which the test infra has rightly noted) |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
154–164 ↗ | (On Diff #356017) | this should be in a separate diff, and also needs a test :) |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
154–164 ↗ | (On Diff #356017) | Well, these are separate issue, yes, but without this change the link wouldn't succeed, ie., it'd trip on the assert on line 156 (on the LHS of the diff) Since these are small enough, can you just let put them in one diff :) |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
154–164 ↗ | (On Diff #356017) | could we not simplify bug_50812.o so that it doesn't trip the assert, then? I think it should be fairly straightforward if you convert it to YAML (or even just hand-craft a YAML test case from scratch) -- one of the advantages of yaml tests is that you can delete most of the extraneous stuff and just test the one code path you're interested in. |
156–157 ↗ | (On Diff #356017) | this isn't necessary, cast<> does the assert in debug mode |
lld/test/MachO/bug_50812.s | ||
---|---|---|
44–111 | try and see if you can delete one or both of these sections and get yaml2obj to accept it. maybe that will also allow the test to pass w/o the Symbol referent changes being in this diff | |
118–130 | should be able to rm these (just remember to update ncmds above) in general yaml test cases should be as small as possible. The goal is not to create a working binary, just to exercise the relevant LLD code paths | |
144 | for clarity, can we add a ## comment on whichever symbols are N_STAB, and remove as many of the other symbols as possible? |
lld/test/MachO/bug_50812.s | ||
---|---|---|
44–111 | (still need the eh_frame) |
lld/test/MachO/bug_50812.s | ||
---|---|---|
6 | I fixed an issue with this test in bf7f846b683077a8adcb229624082e525870229b by adding -o %t to the lld RUN line - without that it tries to write the linked executable to the current working directory which may not be writable/may not be suitable to write to. (might be the test source directory, for instance) But also: This test should probably verify something about the output of the lld execution - currently this test checks for "does anything so long as it exits 0" - perhaps it should check the specific behavior that was untested previously? What specific features of the resulting binary were untested previously/hidden behind this incorrect error? |
lld/test/MachO/bug_50812.s | ||
---|---|---|
6 |
Thanks! (Yeah, I forgot this had caused test failures before when someone was doing an integrate)
This is not a complete binary (because the yaml was trimmed down to make the test small) so the resulting binary wouldn't have run. |
lld/test/MachO/bug_50812.s | ||
---|---|---|
6 |
Tests don't run linked binaries anyway - they might not be built for the host target, etc. I meant testing some properties of the linked binary - same as other lld tests do. (objdumping them to check certain features are present, etc)
So it sounds like maybe this test should be checking that the resulting binary doesn't have any of these debug symbols present? |
I left two comments about the test bug_50812.s on https://reviews.llvm.org/rGbf7f846b683077a8adcb229624082e525870229b#1009321
I think someone may need to investigate how to improve ergonomics of Mach-O yaml2obj. Currently many properties need to be specified which makes a test very verbose and often hides interesting part among boilerplate.
The "address:" is also an issue. Inserting new code can invalid all address fields, making test updating unwieldly.
you're missing a RUN: here (which the test infra has rightly noted)