This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Ignore debug symbols for now.
ClosedPublic

Authored by oontvoo on Jun 30 2021, 9:51 AM.

Diff Detail

Event Timeline

oontvoo created this revision.Jun 30 2021, 9:51 AM
Herald added a reviewer: gkm. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
oontvoo requested review of this revision.Jun 30 2021, 9:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2021, 9:51 AM
int3 added a comment.Jun 30 2021, 3:59 PM

test plz

(I'm genuinely curious about how these symbols are typically generated)

test plz

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
oontvoo updated this revision to Diff 356017.Jul 1 2021, 2:45 PM

updated diff

oontvoo edited the summary of this revision. (Show Details)Jul 1 2021, 2:45 PM
int3 added a comment.Jul 1 2021, 3:22 PM

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)

int3 added inline comments.Jul 1 2021, 5:30 PM
lld/MachO/UnwindInfoSection.cpp
154–164 ↗(On Diff #356017)

this should be in a separate diff, and also needs a test :)

oontvoo updated this revision to Diff 356071.Jul 1 2021, 6:37 PM

added missing RUN

oontvoo marked an inline comment as done and an inline comment as not done.Jul 1 2021, 6:38 PM
oontvoo added inline comments.
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)
IOWs, all of these changes are necessary for the test to pass

Since these are small enough, can you just let put them in one diff :)

int3 added inline comments.Jul 1 2021, 6:44 PM
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

oontvoo updated this revision to Diff 356076.Jul 1 2021, 6:46 PM

use yaml

oontvoo updated this revision to Diff 356078.Jul 1 2021, 6:50 PM
oontvoo marked an inline comment as done.

removed unnecessary assert()

int3 accepted this revision.Jul 1 2021, 7:03 PM
int3 added inline comments.
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?

This revision is now accepted and ready to land.Jul 1 2021, 7:03 PM
oontvoo planned changes to this revision.Jul 1 2021, 7:11 PM
oontvoo edited the summary of this revision. (Show Details)Jul 2 2021, 10:47 AM
oontvoo updated this revision to Diff 356216.Jul 2 2021, 10:50 AM
oontvoo marked 6 inline comments as done.
oontvoo edited the summary of this revision. (Show Details)

split changes in UnwindInfoSection to a separate diff + update test accordingly

This revision is now accepted and ready to land.Jul 2 2021, 10:50 AM
oontvoo added inline comments.Jul 2 2021, 10:50 AM
lld/test/MachO/bug_50812.s
44–111

(still need the eh_frame)

This revision was landed with ongoing or failed builds.Jul 2 2021, 10:53 AM
This revision was automatically updated to reflect the committed changes.
dblaikie added inline comments.
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?

oontvoo added inline comments.Jul 2 2021, 3:14 PM
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)

Thanks! (Yeah, I forgot this had caused test failures before when someone was doing an integrate)

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?

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.
The specific bug we were testing was the fact that debug symbols being present in .o files, which wasn't anticipated before.

dblaikie added inline comments.Jul 2 2021, 3:44 PM
lld/test/MachO/bug_50812.s
6

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.

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)

The specific bug we were testing was the fact that debug symbols being present in .o files, which wasn't anticipated before.

So it sounds like maybe this test should be checking that the resulting binary doesn't have any of these debug symbols present?

MaskRay added a subscriber: MaskRay.Jul 2 2021, 3:53 PM

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.