Page MenuHomePhabricator

[dsymutil] Add reproducers to dsymutil
ClosedPublic

Authored by JDevlieghere on Tue, May 5, 1:32 AM.

Details

Summary

Add support for generating a dsymutil reproducer, which is a folder containing all the object files for linking. When --gen-reproducer is passed, dsymutil uses a FileCollectorFileSystem which keeps track of all the files used by dsymutil. These files are copied into a temporary directory when dsymutil exists. When this path is passed to --use-reproducer, dsymutil uses a RedirectingFileSystem that will use the files from the reproducer directory instead of the actual paths. This means you don't need to mess with the OSO path prefix.

Diff Detail

Event Timeline

JDevlieghere created this revision.Tue, May 5, 1:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptTue, May 5, 1:33 AM
Herald added a subscriber: mgorny. · View Herald Transcript

This needs tests and some polish but please let me know what you think of the general approach.

avl added a comment.Tue, May 5, 5:18 AM

generally it looks good for me, I only have a couple of inline comments.

llvm/tools/dsymutil/Reproducer.cpp
42

It looks like it is not an error, but just logging. Thus it should probably be put under Verbose flag?

if (Options.Verbose)
      outs() << "Reproducer written"
llvm/tools/dsymutil/dsymutil.cpp
101

it would be good to initialize this:
ReproMode = ReproducerMode::Off;

aprantl added inline comments.Tue, May 5, 10:29 AM
llvm/tools/dsymutil/Options.td
167

is there a reason why this isn't called --generate-reproducer? People are not going to call this very often (I hope!) so we should optimize for legibility?

171

What about --record-reproducer and --replay-reproducer?

JDevlieghere marked 5 inline comments as done.Tue, May 5, 11:11 AM
JDevlieghere added inline comments.
llvm/tools/dsymutil/Options.td
167

I did it for consistently with clang, which has the same flag.

171

It's funny you say this because that's what I had originally. It would certainly be more consistent with lldb. I changed it because I don't think "replay" is accurate for dsymutil. I don't plan on capturing anything beyond the input files, so really there's nothing being "replayed". The functionality is more closely related to what clang does, which is why I went with "generate" instead of "capture".

llvm/tools/dsymutil/Reproducer.cpp
42

It's more than logging, it's the only way to find out where the reproducer has been written. I'll change it to outs(), but I don't think it should be behind the Verbose flag.

avl added inline comments.Wed, May 6, 4:12 AM
llvm/tools/dsymutil/Reproducer.cpp
42

I see. Let it be just outs() then.

JDevlieghere marked 2 inline comments as done.
  • Address code review feedback
  • Add tests
JDevlieghere retitled this revision from [WIP][dsymutil] Add reproducers to dsymutil to [dsymutil] Add reproducers to dsymutil.Sun, May 17, 12:31 PM
aprantl added inline comments.Mon, May 18, 10:24 AM
llvm/test/tools/dsymutil/X86/reproducer.test
28

most of these should be CHECK-NEXT?

llvm/test/tools/dsymutil/cmdline.test
5

What do you think about adding

RUN: cat dsymutil.rst | FileCheck --check-prefix=HELP

here to ensure all options are documented?

llvm/tools/dsymutil/Options.td
171

Can you add these to the man page as well?

JDevlieghere marked 4 inline comments as done.
  • Use CHECK-NEXT
llvm/test/tools/dsymutil/cmdline.test
5
friss accepted this revision.Wed, May 20, 3:34 PM

I don't know enough about the VFS to do a thorough review, but the high level logic SGTM

This revision is now accepted and ready to land.Wed, May 20, 3:34 PM

My bots fail with:

../../llvm/tools/dsymutil/Reproducer.cpp:10:10: error: 'Reproducer.h' file not found with <angled> include; use "quotes" instead
#include <Reproducer.h>
         ^~~~~~~~~~~~~~
         "Reproducer.h"

Any reason for the <> include style?

My bots fail with:

../../llvm/tools/dsymutil/Reproducer.cpp:10:10: error: 'Reproducer.h' file not found with <angled> include; use "quotes" instead
#include <Reproducer.h>
         ^~~~~~~~~~~~~~
         "Reproducer.h"

Any reason for the <> include style?

No, must have been unconscious/unintentional. Fixed in d395eacca579858972fd4f79f4c9637db7666392.

This revision was automatically updated to reflect the committed changes.