Tarmik wrote: > On Nov 21, 5:41 pm, Benjamin Smedberg <[EMAIL PROTECTED]> wrote: >> Tarmik wrote: >>> 1. dehydra port for cygwin (windows) environment - >>> currently stuck, since I did not receive any reply on another thread. >> Can you explain *why* you want to do this. As we discussed in the other >> thread, getting GCC plugins to work in a Windows host environment could be >> very difficult because the Windows PE executable format doesn't support a >> DLL importing functions from the primary executable without special export >> libraries. This magic is very hard. > > If I need only dehydra for code analysis - I would switch to linux. > I have linux expirience and played around with ddd. > But steps 3 & 4 dicatates to me that I will need to have decent > debugger, since I > will need to develop infra structure similar to gcc trees. > Step 2 is only intermediate step for 3 & 4.
gdb has some problems, no doubt, but it's still a fairly effective debugger if you know how to use it... and especially if you compile your code with -g3 so that GDB can expand macros. > But weak linking is not a showstopper - there is a possibility to > extract interface > which dehydra wants from gcc, and try to cleanly rewrite/specify it. > It's also in dehydra intrest - who can guarantee you that in gcc > 4.8.9 > internal_error, host_integerp, warning or error function calls ? We have no desire to have a stable interface between GCC and the plugin: we hope to eventually provide a relatively stable interface at the JS level, but we are still bound by the actual implementation of GCC trees and internals. A stable interface would slow down GCC and plugin development in unacceptable ways: we're more interested in tracking GCC development than trying to make it stable. > Btw - currently dehydra is bound to c++ frontend, merely because you > cannot modify const tables - > like tree_code_type. If you would like to switch front end - e.g. to c > or to java - then best approach would be able > to modify those const tables. (tree_code_type, tree_code_length, > tree_contains_struct) Why? It seems easier to simply compile a different dehydra plugin for the C frontend using its definitions, than attempt to build a single plugin to work with different compilers. >> I strongly recommend that you do this hacking on Linux instead of Windows.. > > Hmm... Intrested idea btw... I just don't have native linux os > installed on my pc computers, > but may be I could install that one. > > I need anyway to learn how dehydra works, so it's irrelevant whether > I'm learning it on linux or on windows. The fact that dehydra actually works on Linux and probably won't work on Windows should be a pretty compelling argument for installing VMWare and trying this on Linux ;-) We may even have a Linux VM image that is set up to do analysis already; I'm not sure. --BDS _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
