[PATCH] D49383: [cfi-verify] Support cross-DSO by treating certain calls as traps.
Peter Collingbourne via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 27 14:33:39 PDT 2018
pcc added a comment.
In https://reviews.llvm.org/D49383#1178807, @jgalenson wrote:
> Thanks for the explanations! pcc, that example API was very helpful. I have the core part of it working, including integration with cfi-verify and objdump. I'll finish it up and put the patches up for review at some point.
Great!
> I have a few questions:
>
> Is there a reason you suggested the `getPltAddresses` method should return a `DataRefImpl` instead of a `SectionRef`? The latter seems easier to use.
You mean a `SymbolRef`? Yes, I think it should return one of those instead.
> Is the reason to avoid having `findPltEntries` use the disassembler just to be more lightweight or avoid the extra dependency? Re-implementing even just a tiny portion of it seems a bit strange to me.
Main advantage is simplicity: there's no need to use a generic disassembler here when a simple specialized one would do.
> The 64-bit x86 PLT format seems pretty straightforward, but the 32-bit format seems to contain just an offset from the beginning of the GOT. Am I missing a simple way to use that to compute the GOT virtual address for a PLT entry, or do I need to extend the API to give it a way to compute the GOT base address?
It seems fine to pass the `.got` address into `findPltEntries` as well.
> Also, I assume it's fine for X86MCInstrAnalysis to try both the 32 and 64-bit decodings to see if either matches.
It seems better to pass a target triple or something into the function so that it knows which instruction set to use. There may also be architectures where this is a critical piece of information, such as architectures which support multiple instruction endiannesses.
https://reviews.llvm.org/D49383
More information about the llvm-commits
mailing list