This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Initial groundwork for -bitcode_bundle
ClosedPublic

Authored by int3 on Apr 16 2021, 7:57 AM.

Details

Reviewers
gkm
Group Reviewers
Restricted Project
Commits
rGca6751043d88: [lld-macho] Initial groundwork for -bitcode_bundle
Summary

This diff creates an empty XAR file and copies it into
__LLVM,__bundle. Follow-up work will actually populate the contents of
that XAR.

Diff Detail

Event Timeline

int3 created this revision.Apr 16 2021, 7:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2021, 7:57 AM
Herald added subscribers: dang, mgorny. · View Herald Transcript
int3 requested review of this revision.Apr 16 2021, 7:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2021, 7:57 AM
int3 updated this revision to Diff 338147.Apr 16 2021, 9:12 AM

add test for when libxar isn't available

int3 planned changes to this revision.Apr 16 2021, 9:35 AM
gkm accepted this revision.Apr 16 2021, 9:40 AM
gkm added a subscriber: gkm.

👍🏼

lld/MachO/SyntheticSections.cpp
34–39

These headers already internally have C(++) compatibility.

1045–1060

For my info ... what is special about xar errors that we need special error-handling infra? If it's not special, will other code benefit from the new infra?

int3 marked an inline comment as done.Apr 16 2021, 11:03 AM
int3 added inline comments.
lld/MachO/SyntheticSections.cpp
34–39

ah thanks. This was copypasta...

1045–1060

Most LLVM code is nice enough to return something other than a raw int for error handling. But if we find more use cases for this we can for sure factor it out

Are there plans for an LLVM LIBXAR?

int3 marked an inline comment as done.Apr 16 2021, 11:21 AM

Are there plans for an LLVM LIBXAR?

Not particularly. There are several good reasons to write one though:

  1. libxar's interface doesn't allow for *not* writing to disk
  2. It doesn't support Windows
  3. As mentioned in the other comment, it exposes a rather primitive C interface that is out of place in LLVM's C++

However... I don't think any of the above make it enough of a priority for the people currently working on LLD-MachO. I was actually considering proposing it as a GSoC project, but I see that the deadline for this year has passed. You're welcome to take a stab at it if you want :)

I see your point. It is more in terms of portability and a nicer API.

This revision is now accepted and ready to land.Apr 16 2021, 1:46 PM
This revision was landed with ongoing or failed builds.Apr 16 2021, 1:48 PM
This revision was automatically updated to reflect the committed changes.