This is an archive of the discontinued LLVM Phabricator instance.

[dsymutil] Implement the BinaryHolder object and gain archive support.
ClosedPublic

Authored by friss on Dec 16 2014, 1:03 PM.

Details

Summary

This object is meant to own the ObjectFiles and their underlying
MemoryBuffer. It is basically the equivalent of an OwningBinary
except that it efficiently handles Archives. It is optimized for
efficiently providing mappings of members of the same archive when
they are opened successively (which is standard in Darwin debug
maps, objects from the same archive will be contiguous).

Of course, the BinaryHolder will also be used by the DWARF linker
once it is commited, but for now only the debug map parser uses it.

With this change, you can run llvm-dsymutil on your Darwin debug build
of clang and get a complete debug map for it.

A more 'process' related question to my beloved reviewers: I expect most
code drops of new functionality to the dsymutil tool to be medium sized
patches like this one. I would expect it is OK for me do proceed with this
things doing post-commit review, but I don't want to break any rule like
I did for the initial commit. Opinions?

Diff Detail

Event Timeline

friss updated this revision to Diff 17357.Dec 16 2014, 1:03 PM
friss retitled this revision from to [dsymutil] Implement the BinaryHolder object and gain archive support..
friss added reviewers: samsonov, dblaikie.
friss updated this object.
friss added a subscriber: Unknown Object (MLST).
samsonov edited edge metadata.Dec 17 2014, 6:23 PM

Looks mostly good.

tools/dsymutil/BinaryHolder.cpp
59

You should check that Filename is long enough.

65

This loop occupies 6 lines. Please add {} around its body.

78

Hm, don't you need to take the last opening parenthesis?

tools/dsymutil/BinaryHolder.h
84

Can we use smth. like object_error::invaild_file_type here?

90

You can add

assert(CurrentObjectFile);

here to make this code more self-documented.

93

s/must have to be knwo/must be known

friss added a comment.Dec 18 2014, 9:10 AM

Thanks, will resubmit with you feedback. Some comments:

tools/dsymutil/BinaryHolder.cpp
59

If Filename startsWith CurArchiveName, then FileName[CurArchiveName.size()] is valid because these StringRefs come from std::strings that are null terminated.

78

Not here, we are extracting the archive name. When we extract the member name in GetArchiveMemberBuffer we drop the last character.

samsonov added inline comments.Dec 18 2014, 11:16 AM
tools/dsymutil/BinaryHolder.cpp
59

Right, but if StringRef is a type of an argument in your public interface, it's better not to depend on the fact that these StringRef's will come from a particular source.

78

I mean last *opening* parenthesis. Can we have a Filename:

my(small)archive.a(member.o)
friss added inline comments.Dec 18 2014, 11:29 AM
tools/dsymutil/BinaryHolder.cpp
59

Makes sense, I'll add the check.

78

Sorry for the confusion. Unfortunately, I think there's no nice way to handle this. The member could very well have an opening parenthesis in its name, making the last opening parenthesis the wrong one too. An option would be to try every parenthesis in the filename in turn, but I'd rather leave that out of this patch (not sure we ever want to handle it).

friss updated this revision to Diff 17499.Dec 19 2014, 10:24 AM
friss edited edge metadata.
  • Address review comments.
samsonov accepted this revision.Dec 22 2014, 6:28 PM
samsonov edited edge metadata.

LGTM, with comments below addressed.

tools/dsymutil/BinaryHolder.cpp
59

will this work?

Filename.startswith(Twine(CurArchiveName, "(").str())
107

s/ErrOrMemBufferRef/ErrOrObjectFile

tools/dsymutil/BinaryHolder.h
76

Does it need to be a public method?

This revision is now accepted and ready to land.Dec 22 2014, 6:28 PM
friss added inline comments.Jan 5 2015, 10:09 AM
tools/dsymutil/BinaryHolder.cpp
59

This would certainly work, but it adds a string copy. Not that this will show up on profiles though... OK.

107

sure. Leftover from an old implementation.

tools/dsymutil/BinaryHolder.h
76

Not in this version of the patch, but I don't see a compelling reason to make it private. Consumers that don't care about the object file type should call this method (the Dwarf linker is one of these consumers). Any strong objection to leaving it public?

samsonov added inline comments.Jan 5 2015, 10:13 AM
tools/dsymutil/BinaryHolder.h
76

No, not really. Feel free to leave it public.

This revision was automatically updated to reflect the committed changes.