As discussed via email, we want dehydra to be able to process more than C++: objective-C/objective-C++ for sure, because we have mac XPCOM code written in these languages.
Just as an update, I've worked out the weak symbol incantations that allow the same plugin to load into the different compiler executables successfully, and am working on the best way to pick up all the declarations, most likely a tweak to the compiler's c-decl.c to collect them all in a form similar to global_namespace in the C++ front end.
This is the current state of my work for C support; it doesn't include some experimental tweaks to the C frontend (such as to call plugin_cp_pre_genericize). The key thing to note is the weak pragma attached to global_namespace; the definition to NULL in the plugin will guarantee that it is empty for non-C++, but then is overridden by the definition in cc1plus and cc1objplus.
Kevin(In reply to comment #3) > Created an attachment (id=319635) [details] > Use dlopen to remove hard symbol dependency > As written, this will break mac.
lets not worry about breaking mac until we get close to landing features :)
:) we are doing it quite often even when we are close, but sure I agree. Just a minor note.
(In reply to comment #4) > As written, this will break mac. > I assume your talking about the use of dlopen. That will have to be made more portable. My patch does uncover another c++ symbol cp_walk_subtrees. Because it is inserted by a macro, it was a little difficult to hunt down.
Unfortunately platform differences proved to be of lesser importance than gcc version differences for maintaining xhydra on mac. There is a dlopen emulation layer on a mac which works adequately and we use it to build plugin-capable gcc there. The gcc differences, on the other hand, are mostly undocumented and usually we just run into them. What I noticed in the patch is directly using "walk_tree_without_duplicates_1" which doesn't exist as such in mac gcc42 we build with. But as I said, I agree with Taras that this stuff is not of paramount importance until the feature is more or less complete on linux and ready to land, so don't worry about mac too much, so far we were able to come up with not-so-elegant-at-times solutions for these issues. Obviously it wouldn't hurt if the patch were mac-compatible but it is ok if it is not.
Since I'm actually developing this patch on a Mac, chances are it will work there right from the start. :-)
Stan, any progress? Do you have a new patch? The last one I got still has symbols that where not present when using gcc instead of g++. Kevin
Here is what I expect to be the last version of my work on this. I didn't include Kevin's bits for dynamic loading, because the Mac implicitly makes functions weak and so the issue didn't come up. There is an associated patch in the compiler to get a pointer to tree structures in the C/ObjC frontends - it was supposed to be a chain of structs in chain_for_plugin, but for reasons I don't really understand it seems to be sufficient just to set it to each tree individually.
Attachment #319625 - Attachment is obsolete: true
Kevin, This might be helpful for you. With this patch dehydra "works" with GCC. it doesn't do method bodies, just enums/structs/unions. The only additional change needed in GCC is to call plugin_finish_struct(type) in rest_of_type_compilation.
I think this is as far as I can take C dehydra in terms of being able to generate treehydra. The fundamental limitation of C FE in not using DECLs for types means that there is context info on C structs so it do some of the GTY stuff such as the stuff needed to support C++ types. One could just hardcode struct nesting info, but that's ugly.Can't do tricks involving reading the file either because C FE's struct positions are so terrible. Dave, could you check that this patch doesn't break any of your stuff?
Comment on attachment 327008 [details] [diff] [review] C compat patch for Dehydra My analyses work fine with it.
Attachment #327008 - Flags: review?(dmandelin) → review+
Dehydra and treehydra are no longer maintained by Mozilla.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.