The feature is implemented directly in the Image.create function so
that it can be used programmatically. The backend parameter can now
accept an explicit file path instead of the loader name. The
documentation of the loader command-line parameter is accordingly
updated.
To prevent clashes between existing loaders and filenames, only
existing filenames with explicit paths are treated as OGRE
specifications, i.e., the path must start with ./, ../, or / in
Unix.
Example of usage,
$ bap testsuite/bin/arm-linux-gnueabi-echo -dogre:echo.ogre -dbir | grep print_endline
000007da: sub print_endline(print_endline_result)
00000804: print_endline_result :: out u32 = R0
0000031e: call @print_endline with return %00000320
$ sed 's/print_endline/printl/g' echo.ogre > echo.mangled.ogre
$ bap testsuite/bin/arm-linux-gnueabi-echo --loader=./echo.mangled.ogre -dbir | grep printl
00000339: call @printl with return %0000033b
000007df: sub printl(printl_result)
00000807: printl_result :: out u32 = R0
You can also use bap specification ./exe to obtain the initial OGRE
specification for a file (without disassembling it) and the edit it to
your taste. And, of course, you can write a specification from
scratch.
The feature is implemented directly in the
Image.createfunction so that it can be used programmatically. Thebackendparameter can now accept an explicit file path instead of the loader name. The documentation of theloadercommand-line parameter is accordingly updated.To prevent clashes between existing loaders and filenames, only existing filenames with explicit paths are treated as OGRE specifications, i.e., the path must start with
./,../, or/in Unix.Example of usage,
You can also use
bap specification ./exeto obtain the initial OGRE specification for a file (without disassembling it) and the edit it to your taste. And, of course, you can write a specification from scratch.