[llvm] r182628 - MC: Disassembled CFG reconstruction.

Ahmed Bougacha ahmed.bougacha at gmail.com
Fri Jun 14 16:31:16 PDT 2013 

On Fri, Jun 14, 2013 at 6:35 AM, Bloom, Louis S. <lbloom at draper.com> wrote:
> Hi Ahmed,
>
> I've been playing with this CFG reconstruction patch and discovered
issues with branch evaluation when the operands are encoded as MCExpr types
instead of immediates. This is a problem when a disassembler has been set
up for symbolic disassembly as many operands are encoded as MCExpr types.
See attached patches, I modified the evaluateBranch function inside of
MCInstrAnalysis.cpp in order to handle branch evaluation of MCExpr types. I
have also modified the tryAddingSymbolicOperand function inside of
MCExternalSymbolizer.cpp to encode the immediate values necessary within
MCExpr types as they correspond to the immediate operands which the symbols
they replace. Ultimately, this allows for CFG reconstruction to occur as
expected even during symbolic disassembly.
>
> The patches do the following:
>
> * ext-sym-patch1.txt - Adds the original immediate value to symbolic
operands.
> * instr-anal-patch2.txt - Using ext-sym-patch1.txt, adds support for
branch evaluation by evaluating MCExprs as immediates.

Hi Louis,

There are definitely lots of improvements to be made in the area, thanks for
having a look!  I am currently working on stuff that will eventually need
this,
but even though you're on the right track, the patch needs a few changes.

- First, the value set to an MCSymbol should be the symbol's absolute value.
  In this case, the patches make two changes that cancel each other out:
  + in evaluateBranch, we only need to add Addr+Size to immediate
PC-relative
    operands, and not to the result of EvaluateAsAbsolute (which, as the
name
    indicates, returns an absolute value, as opposed to a PC-relative one).
  + in MCExternalSymbolizer, the values assigned to the MCSymbols should be
    absolute ("Value"), not PC-relative-ish ("- Address - Offset -
InstSize").

- For both SymbolicOp.AddSymbol and .SubSymbol, the patch sets the same
ImmVal,
  which is the one that's already in SymbolicOp.Value. The correct values
can't
  be determined in MCExternalSymbolizer, since the C API states that, in the
  LLVMOpInfoSymbol1 struct, you can't have both .Name and .Value, which is
the
  correct value in this case.

- This brings us to another point: we've shown that this can't easily work
for
  MCExternalSymbolizer, but this isn't actually a problem, since if you can
  create an MC CFG, you need an ObjectFile, which is enough to run the
  MCObjectSymbolizer. Basically, MCExternalSymbolizer shouldn't change, as
it's
  used in places (otool, lldb) where you "can't” create an MC CFG anyway.
  MCObjectSymbolizer should, as they both interact when you run
  'llvm-objdump -cfg -symbolize’. If you somehow setup your own symbolic
  callbacks on an MCDisassembler you give to MCObjectDisassembler,
  you should switch to MCObjectSymbolizer!

- If the generic evaluateBranch should handle MCExprs, then so should the
  target-specific ones (look at *MCTargetDesc.cpp for both AArch64 and ARM).


All in all, there are two possibilities here:
- either working around the problem: in llvm-objdump, moving the "if (CFG)”
  block to before the "if (Symbolize)” one, and ensuring (documentation +
  assert) that the disassembler given to an MCObjectDisassembler doesn’t
  have symbolization enabled (this is redundant/useless for the current
  MCObjectDisassembler anyway).
- properly handling MCExprs in MCInstrAnalysis, and setting the right
  value whenever we create an MCSymbol, given the comments above.

Thanks!

-- Ahmed Bougacha

> Very Respectfully,
> LOUIS S. BLOOM, 2d Lt, USAF
> AFIT Student - Northeastern University
> Draper Laboratory Fellow
>
> DISCLAIMER: The views expressed are those of the author and do not
reflect the official policy or position of the Department of Defense or the
U.S. Government.
>
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:
llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Ahmed Bougacha
> Sent: Thursday, May 23, 2013 9:07 PM
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm] r182628 - MC: Disassembled CFG reconstruction.
>
> Author: ab
> Date: Thu May 23 20:07:04 2013
> New Revision: 182628
>
> URL: http://llvm.org/viewvc/llvm-project?rev=182628&view=rev
> Log:
> MC: Disassembled CFG reconstruction.
>
> This patch builds on some existing code to do CFG reconstruction from
> a disassembled binary:
> - MCModule represents the binary, and has a list of MCAtoms.
> - MCAtom represents either disassembled instructions (MCTextAtom), or
>   contiguous data (MCDataAtom), and covers a specific range of addresses.
> - MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
>   backed by an MCTextAtom, and has the usual successors/predecessors.
> - MCObjectDisassembler creates a module from an ObjectFile using a
>   disassembler. It first builds an atom for each section. It can also
>   construct the CFG, and this splits the text atoms into basic blocks.
>
> MCModule and MCAtom were only sketched out; MCFunction and MCBB were
> implemented under the experimental "-cfg" llvm-objdump -macho option.
> This cleans them up for further use; llvm-objdump -d -cfg now generates
> graphviz files for each function found in the binary.
>
> In the future, MCObjectDisassembler may be the right place to do
> "intelligent" disassembly: for example, handling constant islands is just
> a matter of splitting the atom, using information that may be available
> in the ObjectFile. Also, better initial atom formation than just using
> sections is possible using symbols (and things like Mach-O's
> function_starts load command).
>
> This brings two minor regressions in llvm-objdump -macho -cfg:
> - The printing of a relocation's referenced symbol.
> - An annotation on loop BBs, i.e., which are their own successor.
>
> Relocation printing is replaced by the MCSymbolizer; the basic CFG
> annotation will be superseded by more related functionality.
>
>
> Added:
>     llvm/trunk/include/llvm/MC/MCFunction.h
>     llvm/trunk/include/llvm/MC/MCObjectDisassembler.h
>     llvm/trunk/include/llvm/Support/StringRefMemoryObject.h
>     llvm/trunk/lib/MC/MCFunction.cpp
>     llvm/trunk/lib/MC/MCObjectDisassembler.cpp
>     llvm/trunk/lib/Support/StringRefMemoryObject.cpp
> Removed:
>     llvm/trunk/tools/llvm-objdump/MCFunction.cpp
>     llvm/trunk/tools/llvm-objdump/MCFunction.h
> Modified:
>     llvm/trunk/include/llvm/MC/MCAtom.h
>     llvm/trunk/include/llvm/MC/MCInstrAnalysis.h
>     llvm/trunk/include/llvm/MC/MCModule.h
>     llvm/trunk/lib/MC/CMakeLists.txt
>     llvm/trunk/lib/MC/MCAtom.cpp
>     llvm/trunk/lib/MC/MCInstrAnalysis.cpp
>     llvm/trunk/lib/MC/MCModule.cpp
>     llvm/trunk/lib/Support/CMakeLists.txt
>     llvm/trunk/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
>     llvm/trunk/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp
>     llvm/trunk/tools/llvm-objdump/CMakeLists.txt
>     llvm/trunk/tools/llvm-objdump/MachODump.cpp
>     llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp
>     llvm/trunk/tools/llvm-objdump/llvm-objdump.h
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130614/c64b4743/attachment.html>

More information about the llvm-commits mailing list