Tarmik wrote:
Other functions are more complex. For instance - 'expr_as_string'
equalent does not exists in C source codes.
Can someone provide me more information on what those functions do,
and how c++ / c remapping could be potentially handled ?
I'd just make some stubs for those functions that return strings and
return "not implemented" and otherwise unhelpful values and see how far
you get. You can read g++ source to figure out what the various
functions do.
On a possibly related topic.
So I don't know much about cygwin/windows porting. From what I heard
from plugin discussion on the gcc mailing list, you need to explicitly
export ALL of the symbols in windows GCC in order to match the linux
dlopen behavior..but perhaps cygwin takes care of that.
Yes, I was discussing on that subject. Cygwin does not magically
exports anything,
unfortunately for me. I've already tried to make - e.g.
// Defined in C++ front end (gcc/cp) - but can be used for C front end
as well.
const char * decl_as_string (tree decl, int flags);
but that results in linker errors - most probably c frontend is linked
separately from c++ frontend.
I'm bit curious how it works on linux... When I've tried to copy-paste
function implementations
from cp\error.c - I've run into problems of cross dependencies -
decl_as_string requires dump_decl function, dump_decl requires
dump_type functions, and so on...
I've tried also to include error.c as such, but then I have a
collision of c and c++ front ends -
they both declare the same structure and the same data types causing
again compilation errors.
Best approach would be to cherry pick all necessary functions from cp
\error.c with all their dependencies
, but it's bit heavy job for human, can this be done by dehydra ?
Can I compile dehydra with my own java scripts which would locate
functions which I'll need
(e.g. decl_as_string), figure out it's dependencies - and will be able
to copy paste lines from original code into
my own - e.g. cp\error.c > c_cp_common_functions.c.
I guess answer would be yes, but how complex it is actually ?
Hard. Code extraction out of C sounds troublesome.
I really don't see why you refuse to use linux for this. Confusing
porting dehydra to C with porting to cygwin is enough to get anyone's
head spinning. On linux we make use of lazy linking so functions are
aren't present in the C frontend have a null value, then we avoid
calling those functions when they arent present.
So as I mentioned before, dealing with cygwin seems like a massive waste
of energy. If you want to analyze win32 code, then setup a
linux-to-win32 crosscompiler.
Cheers,
Taras
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
