ivg on master
adds the list of supported arch… (compare)
ivg on switch-to-omake
ivg on switch-to-omake
fixes library dependencies The… adds OMakefiles They describe … cleans up the main Makefile and 7 more (compare)
Well, if you compare with languages that have dynamic types, then yes. For example, Python lets you right total garbage that looks like a Python program and only in runtime tells you that it is not well-formed. In that sense, OCaml is much more strict, and won't accept your program unless it type checks.
If you will compare with statically typed languages, then I don't believe that C++ type errors are any better. Or , even, rust errors.
Especially now, when error messages got improved with each new release of OCaml. And we also have merlin, so you do not postpone error checking until it is hard to understand. With merlin is much easier now. You type new code and if merlin highlights it, then something is wrong with your code. Usually, I don't even bother myself reading the error message. It's like with the spellchecker, once it highlights you see that the word is wrong.
But even today, some people are trying to use OCaml without Merlin - and this brings us back to the infrastructure problem.
Concerning Rust bindings, they do exist, and we indeed didn't update them to the latest 2.0 interface. There is only one function that needs to be added/updated
bap_init, @gitoleg will do this. Meantime, I will ask Matt to transfer the repo to us, so that it will be easier for people to find them (and so that they look more maitained).
Update: added the link
Merlin is incremental, it types as you types. So when you start writing a program it will immediately show you the error in the place where you type. Like if you write
let example () = List.map (fun x -> x + 1) ["hello"]
it will immediately highlight
This expression has type string but an expression was expected of type int. So merlin errors will be always at the place where the error occurs when you develop a program. If you take an already broken program and then ask Merlin what went wrong, then yes, your comment is applicable.
But, it is essential, not to postpone type checking, the same as with testing and integration. The sooner you type check the better.
Concerning annotations. You're not enforced to use them but highly encouraged. I usually pack all my functions into many small modules, each sealed with an interface. This limits both the scope of the typing and the scope that you have to reason about.
To summarize - small functions, packed into small modules, these are our building blocks. The smaller the block the easier it is to handle it.
Also, it is usually a good idea to employ the
bap utility and write your analysis as a plugin to it. For example, you can write a disassembly pass and get your function called on the disassembled file without having the burden of specifying all the parts manually. E.g., if you will write a simple program,
open Bap_main let main proj = () let () = Extension.declare @@ fun _ctxt -> Project.register_pass' main
main function will be called with the project data structure that includes all the information associated with the disassembled target, e.g.,
Project.program proj will contain the disassembled program in IR,
Project.disasm proj will be the disassembly. You can also obtain the image and other properties, if needed.
I'm using bap 2.0.0, I'm wanting to call the bap disassembler (and maybe more) from inside a large pre-existing ocaml project. My main goals is to get the list of instruction names, parameters and labels to convert to a representation in this other project. i.e.
insns produces type
(Bap.Std.mem * Bap.Std.insn) Bap.Std.seq which would be ideal for my use case.
Is my plugin issue mainly that I need to
init Project to initialize the correct global state? I'm not sure how well the plugin style dev will work for my use case (I can't use bapbuild etc and have to work with ocamlfind).
Thanks for all of the feedback :)
Ah, I just saw
passthat doesn't modify the project effect and is run only for side effect. (See register_pass)
Think I might just need to do a bit more reading through the docs.
terminate called after throwing an instance of 'SerializedTrace::TraceException' what(): Unable to parse from string
I do not know the current state of support for loading those traces into bap 2.0 and would be curious to know
This traces could be loaded and processed in OCaml using the
trace plugin and the Bap_traces library. We're also planning to release after the holidays, code that enables support for old versions of Bil, e.g., those that were used in BAP 0.8.x, this should also help you in porting the old code :)
bapbuild is used for building and installing plugins right? I'm trying to use a subset of bap's features as part of an interpreter to do some experimental things, so I'm not sure loading the extension as a plugin will work...
And even after paying attention to the warning in the
Bap_main.init () I can't seem to call it without my program seg faulting.
I've managed to compiler a test file with
ocamlfind ocamlopt -o out -linkpkg bap -package Findlib.dynload and not seg faulted. But when compiling the main project to lots of .cmx and then linking the resulting program segfaults.
I'm using these options
ocamlfind ocamlopt -bin-annot -g -I extraction -I lib -I common -I x86 -I backend -I cfrontend -I cparser -I driver -I exportclight -I debug -I <Menhirlib> -w +a-4-9-27 -strict-sequence -safe-string -package Findlib.dynload -linkpkg -package bap <lots of .cmx>
In case any of those might be interfering.
(I've tried using the
Findlib.record_package function but I'm not sure what arguments to call it with lol
findlib.dynloadis typed without capitalization (though if you're on mac it might not matter, or might do)
-package bapand do
Bap_main.inityou shall not specify any cmx from bap or anything like this
-Ioptions refer to you own subfolders it could be very possible, that we have a name conflict in some compilation unit. Or that you have a conflict with the compiler-libs. In general, it is a good idea to prefix all your compilation units (ml files) with the name of your project, so not
my_project_parser.ml(you can use dune, it will handle this mangling for you)
1) Woops thats a mistype in my gitter message, the build script uses
2) yah, the cmx's are linking with all of the other cmx files at the build stage, I'm adding
-linkpkg -package bap and
package findlib.dynload to the ocamlfind options
3) Could be, will investigate
4) Will have a look
5) If 4 and 5 don't reveal anything, will do.
6) I'm using 4.06.1, will be a pain to update but might come to it
Thanks so much for the help!!
-packageoption. It won't track your local libraries specified on the command line via *.cmx[,a,s] files.
The rule is simple, there shouldn't be any compilation units with the same name. So most likely the conflict comes from some of your internal. It is unlikely that it conflicts with some bap module, as we prefix all our modules (unless you also prefixed your module with
bap_<xxx>). I think the conflict is with some external library. Again, look at the log file it may limit our search space.
Also, make sure that you don't have modules named
lexer.* and other generic modules. Ideally, prefix all your modules with your namespace. It has nothing to do with bap in general, it is the limitation of OCaml linking scheme, just bap brings a lot of libraries to the namespace, so it increases the possibility of the conflict.
Also, just a long shot, I see you have some cparser and cfronted, and it could be that you have vendored FrontC, i.e., you have your own copy of frontc inside. This will definitely come into a confict with the frontc library from opam. So if it is true, rename the files, or use the upstream frontc if possible.
FROM ocaml/opam2:ubuntu-18.04 WORKDIR /home/opam RUN sudo apt-get update \ && sudo apt-get install libncurses5-dev --yes \ && opam repo add bap git://github.com/BinaryAnalysisPlatform/opam-repository#testing --all \ && opam switch 4.07 \ && eval "$(opam env)" \ && opam update \ && opam depext --install bap --yes \ && opam clean -acrs \ && rm -rf /home/opam/.opam/4.0[2-6,8,9] \ && rm -rf /home/opam/.opam/4.07/.opam-switch/sources/* \ && rm -rf /home/opam/opam-repository ENTRYPOINT ["opam", "config", "exec", "--"]
letexpressions. IN 1.6.0 this worked as expected and
letwas removed during the normalization. Now I'm seeing no change from the before and after normalization. Same goes for BIL normalization, regardless of BN1 or BN2. Was I suppose to do anything different?