> Yes, exactly. Windows doesn't support the functionality of -rdynamic, so
> running dehydra on a Windows host is pretty much impossible. So we can
> instead use a Linux host, compile our Windows-specific code, and run static
> analysis on it.
Windows specific code, linux specific code... Such code exists only
because noone has figured out
a common interface which would be suitable for both platforms and
after that you don't need to have
os specific code.
After struggling with gcc compilation and dehydra compilation - I can
manage passing now some function
pointers and variable pointers from gcc to dehydra. I've noticed that
running configure
with tree checks disabled --enable-checking=assert,runtime will
disable some of checking functions
in dehydra (and in gcc). Slightly easier - less unresolved symbols.
(ENABLE_TREE_CHECKING define is controlling
additional tree checks).
So now I have specified some calls like this:
plugin_set_param(0,&global_namespace);
plugin_set_param(1,(void*) &tree_contains_struct);
plugin_set_param(5,(void*) &fancy_abort);
plugin_set_param(6,
#ifdef ENABLE_TREE_CHECKING
(void*) &tree_class_check_failed
#else
NULL
#endif
);
plugin_set_param(7,
#ifdef ENABLE_TREE_CHECKING
(void*) &tree_contains_struct_check_failed
#else
NULL
#endif
);
Main problem with that approach - is that each function prototype
needs it's own
wrapper, each global data variable - memcopying or passing through
pointer.
(Memcopied for example 'tree_contains_struct' variable).
E.g. wrote something like this:
gcc_plugin_link.c:
//
// Type def all function prototypes.
//
#define LINK_ENTRY(return_type, function_name, function_args,
call_args, ordinal_number) \
typedef return_type (*pfunc_##function_name) function_args; \
#include "gcc_plugin_link_table.def"
//
// Implement all functions.
//
#undef LINK_ENTRY
#define LINK_ENTRY(return_type, function_name, function_args,
call_args, ordinal_number) \
return_type function_name
function_args \
{
\
if(pFuncCallbacks[ordinal_number] == NULL) printf("error: %d
ordinal is NULL\n", ordinal_number); \
((pfunc_##function_name) pFuncCallbacks[ordinal_number])
call_args; \
}
#include "gcc_plugin_link_table.def"
where gcc_plugin_link_table.def:
//
// LINK_ENTRY(return_type, function_args, function_name,
ordinal_number)
//
LINK_ENTRY(
void , fancy_abort,
(const char * a, int b, const char * c),
(a,b,c),
5
)
LINK_ENTRY(
void, tree_class_check_failed,
(const_tree a, const enum tree_code_class b, const char * c, int
d, const char * e),
(a,b,c,d,e),
6
)
LINK_ENTRY(
void, tree_contains_struct_check_failed,
(const_tree a,const enum tree_node_structure_enum b,const char *
c, int d, const char * e),
(a,b,c,d,e),
7
)
----------------------------------------------------------------------------------------------------
but this suffers further problems - like if function will have return
variable - then wrapping above might not work.
:-/
I have found some mentions about trampolines -
http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
does anyone knows something about them / usage examples.
Once upon I time I've made some vsock32.dll wrapper using i386
assembler
- and function rounting was pretty easy thing to achieve - you simply
"jmp"
to new address - don't care about calling arguments and return values.
And everything was going smoothly back and forth.
But now I'm not living in assembler world anymore - and such cracking
does not feasible solution to me. On $M compiler has __declspec(naked)
which might have similar influence as assembler "jmp", but not sure
whether
it's available in gcc.
Can anyone recommend me decent way of rerouting bunch of functions
from one place to another ?!
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
