[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