[llvm-dev] LLVM Call Graph may not cover all calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] LLVM Call Graph may not cover all calls

韩玉 via llvm-dev
Hi there,
   I am working with opt-6.0 and try to generate a call graph of libsndfile, but it seems the call graph doesn't cover all call relationship.
   Actually, I am doing static analysis on CVE-2014-8130, which is a zero division on libtiff/tif_write.c  TIFFWriteScanline.   (see https://security-tracker.debian.org/tracker/CVE-2014-8130)
   Theoretically, the main function in tiffdither.c will call fsdither, and fsdither will call TIFFWriteScanLine.   main (tiffdither.c) -> fsdither (tiffdither.c) -> TIFFWriteScanLine (tif_write.c)
   I want to get a call graph of the buggy program tiffdither but I find the call graph generated doesn't cover the call relationship from fsdither ->  TIFFWriteScanLine.
   For short, the call graph now shows TIFFWriteScanLine is only called by an external node.
   I already compile tiffdither, and I upload it as an attached file. I also write a small python to help analyze the dot file.
   Actually, I do  opt-6.0 -analyze -dot-callgraph tiffdither.bc to generate the dot file. And then modify the dotPath in dotHandle.py. You can modify the python code to help analyze.
   I can't figure out why this happens, and I will be very appreciate if you can help!

Thanks & Regards,
Chaz

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

tiffdither.bc (2M) Download Attachment
dotHandle.py (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] LLVM Call Graph may not cover all calls

韩玉 via llvm-dev
How are you generating the calligraph from? Generally a compiler only acts on a per translation unit basis, so it couldn't form the complete program call graph across multiple files (hence why it's missing the edge that crosses the boundary between .C files)

On Thu, Nov 8, 2018, 8:43 AM changze cui via llvm-dev <[hidden email] wrote:
Hi there,
   I am working with opt-6.0 and try to generate a call graph of libsndfile, but it seems the call graph doesn't cover all call relationship.
   Actually, I am doing static analysis on CVE-2014-8130, which is a zero division on libtiff/tif_write.c  TIFFWriteScanline.   (see https://security-tracker.debian.org/tracker/CVE-2014-8130)
   Theoretically, the main function in tiffdither.c will call fsdither, and fsdither will call TIFFWriteScanLine.   main (tiffdither.c) -> fsdither (tiffdither.c) -> TIFFWriteScanLine (tif_write.c)
   I want to get a call graph of the buggy program tiffdither but I find the call graph generated doesn't cover the call relationship from fsdither ->  TIFFWriteScanLine.
   For short, the call graph now shows TIFFWriteScanLine is only called by an external node.
   I already compile tiffdither, and I upload it as an attached file. I also write a small python to help analyze the dot file.
   Actually, I do  opt-6.0 -analyze -dot-callgraph tiffdither.bc to generate the dot file. And then modify the dotPath in dotHandle.py. You can modify the python code to help analyze.
   I can't figure out why this happens, and I will be very appreciate if you can help!

Thanks & Regards,
Chaz
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev