This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Re-add dylink-lazy test
ClosedPublic

Authored by int3 on May 10 2020, 4:43 PM.

Details

Summary

The initial attempt didn't work on Windows; apparently
Powershell has a different syntax for running commands sequentially and
concatenating their outputs. So I've created two temporary files
instead.

Diff Detail

Event Timeline

int3 created this revision.May 10 2020, 4:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 10 2020, 4:43 PM

Do you mean?

# RUN: ( llvm-objdump -d --no-show-raw-insn --syms --bind --lazy-bind %t/dylink-lazy; \
# RUN:  llvm-objdump -D --no-show-raw-insn %t/dylink-lazy ) | FileCheck %s

Does # REQUIRES: shell work? You can watch Harbomaster (pre-merge testing) results on Windows.

int3 updated this revision to Diff 263174.May 11 2020, 7:53 AM

try requiring shell

MaskRay accepted this revision.May 11 2020, 10:48 AM

Looks great!

This revision is now accepted and ready to land.May 11 2020, 10:48 AM
int3 added a comment.May 11 2020, 12:36 PM

Thanks for the pointer @MaskRay!

This revision was automatically updated to reflect the committed changes.

@echristo on llvm-commits: Would this be better off as a yaml2obj file as input? It would remove the assembler checks and even the dyld checks.

In lld/ELF, I find that yaml2obj tests tend to be overly complex. They are occasionally used to synthesize invalid input which can't be generated by an assembler (llvm-mc).
Other than that, they tend to be quite cumbersome. For an example, to represent a jump target which can be relocated, a YAML file needs several lines to represent the text section,
followed by some raw bytes (like using .inst directives in assembly), then another relocation section with a relocation record. These add up to tens of lines.

On the contrary, in assembly, one can achieve that with just one line.

thakis added a subscriber: thakis.May 12 2020, 10:16 AM

FYI, when this landed for the first time, it failed on our windows bots (https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8880710376392097968/+/steps/package_clang/0/stdout). It sounds like it relanded without changes, so chances are it's going to fail there again.

int3 added a comment.May 12 2020, 11:05 AM

@thakis this diff makes the changes to fix the failure in the build you linked to (original failure was from rGb3e2fc931d2e)

Ah cool, sorry for the noise then :)