[PATCH] D76252: [lld-macho] Add basic support for linking against dylibs

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 31 22:00:15 PDT 2020


ruiu added inline comments.


================
Comment at: lld/MachO/Writer.cpp:357-360
+      os << (char)BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM;
+      os << sym->getName() << '\0';
+      os << (char)(BIND_OPCODE_SET_TYPE_IMM | BIND_TYPE_POINTER);
+      os << (char)BIND_OPCODE_DO_BIND;
----------------
int3 wrote:
> ruiu wrote:
> > nit: we usually do
> > 
> >   os << foo << bar
> >      << baz << fizz;
> > 
> > instead of
> > 
> >   os << foo << bar;
> >   os << baz << fizz;
> sgtm. Any thoughts on whether we should make a wrapper class like the ByteBuffer in ReaderWriter/MachO? I didn't see a whole lot of usage of `raw_ostream`s in the other lld implementations but I didn't find any abstraction layer over them either
We don't usually use `raw_ostream` because we usually write to the output file in two passes: in the first pass, we compute an offset for each output element, and then in the second pass, we let each output element to copy itself to the output file.

However, that two-pass technique cannot be used to create a ULEB-encoded stuff. because we don't know the exact size of each output element until we fix the file contents. Constructing an ULEB-encoded section contents are naturally sequential. So the usage of `raw_ostream` in for this section is fine. I don't see any problem with that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76252/new/

https://reviews.llvm.org/D76252





More information about the llvm-commits mailing list