[PATCH] D106128: [lld-macho] Use DO_BIND_ADD_ADDR_IMM_SCALED for bind opcodes
Vincent Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 19 14:54:30 PDT 2021
thevinster marked 3 inline comments as done.
thevinster added a comment.
In D106128#2888416 <https://reviews.llvm.org/D106128#2888416>, @int3 wrote:
> one nit about the commit title / description: there are lots of opcodes with immediates, I think it would be clearer to mention `DO_BIND_ADD_ADDR_IMM_SCALED` specifically in the title. Also "Implement pass 3 of bind opcodes from ld64" should be followed by a short description of what pass 3 does -- we shouldn't expect future readers to have to look it up :)
Done.
================
Comment at: lld/MachO/SyntheticSections.cpp:370
+ if ((p->opcode == BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB) &&
+ (p->data < (BIND_IMMEDIATE_MASK * offsetWidth)) &&
+ ((p->data % offsetWidth) == 0)) {
----------------
int3 wrote:
> thevinster wrote:
> > int3 wrote:
> > > how about `p->data / offsetWidth <= BIND_IMMEDIATE_MASK`, to mirror the assignment below?
> > I changed it to `p->data / target->wordSize < BIND_IMMEDIATE_MASK`. I removed the equals comparison because when dyld uncompacts, it seems to add an extra `sizeof(intptr_t)`.
> >
> > See https://opensource.apple.com/source/dyld/dyld-852/src/ImageLoaderMachOCompressed.cpp.auto.html and search for `address += immediate*sizeof(intptr_t) + sizeof(intptr_t);`
> I think the previous implementation was the right one. The DO_BIND opcode itself adds a `sizeof(intptr_t)`, which is probably why dyld is doing that.
>
> From http://www.m4b.io/reverse/engineering/mach/binaries/2015/03/29/mach-binaries.html 's description of DO_BIND:
>
> > Push the current record onto the "import stack", and then increment the current record's address offset by the size of the platform pointer (32 or 64 bit)
>
> It would be good to have a test case that covers this edge case :)
Re-capping offline convo. In ld64's implementation, it uses "<" instead of "<=". It makes more sense to keep the same behavior to prevent any unknown deviations from ld64. It may be a typo on ld64, but this will prevent unknown mysterious bugs down the road.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106128/new/
https://reviews.llvm.org/D106128
More information about the llvm-commits
mailing list