[PATCH] D75382: [lld] Initial commit for new Mach-O backend

[Jez Ng via Phabricator via llvm-commits]

int3 added inline comments.


================
Comment at: lld/MachO/InputFiles.cpp:106
+    isec->data = {buf + sec.offset, sec.size};
+    isec->align = 1 << sec.align;
+    isec->flags = sec.flags;
----------------
ruiu wrote:
> int3 wrote:
> > ruiu wrote:
> > > int3 wrote:
> > > > MaskRay wrote:
> > > > > What if sec.align is >= 32 ?
> > > > I haven't found the logic in ld64 that handles this, but some experimentation (creating object files with high alignments using yaml2obj and then passing it to ld64) suggests it does applies `mod 256` to `sec.align` w/o emitting warnings or anything. Obviously 2 ** 256 is still ridiculously large, and ultimately `ld64` emits a 2GB object file, so it looks like some silent overflows are happening.
> > > > 
> > > > I'm leaning towards applying `mod 32` here and emitting a warning.
> > > `mod 32` seems a bit too arbitrary, so how about always setting `isec->align` to `sec.align` with a warning if `sec.align` is too large?
> > how do you propose we align the addresses for sections with large `align` values?
> Oh, the first thing I'd like to point out is that we store raw alignment values instead of power-of-two values to `alignment` variables in other ports, and mach-o probably should follow that to avoid confusion, even if it means we compute a power-of-two and then convert it back to an exponent.
> 
> To answer to your question, if you use `uint32_t` for `align` member, the maximum alignment we can represent is naturally limited to 2^31. How about print out an error (instead of warning) if it is greater than that?
Ah, thanks for the explanation. And yeah, I guess ld64's behavior isn't worth emulating, erroring out is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75382