Give dehydra/treehydra the ability to process C/objective-C/objective-C++



11 years ago
Last year


(Reporter: benjamin, Assigned: taras.mozilla)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments, 3 obsolete attachments)



11 years ago
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.

Comment 1

11 years ago
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.

Comment 2

11 years ago
Posted patch WIP patch for C support (obsolete) — Splinter Review
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.

Comment 4

11 years ago
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.

Comment 5

11 years ago
lets not worry about breaking mac until we get close to landing features :)

Comment 6

11 years ago
:) we are doing it quite often even when we are close, but sure I agree. Just a minor note.

Comment 7

11 years ago
(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.

Comment 8

11 years ago
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.

Comment 9

11 years ago
Since I'm actually developing this patch on a Mac, chances are it will work there right from the start. :-)


11 years ago
Blocks: 437502

Comment 10

11 years ago
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++.


Comment 11

11 years ago
Posted patch Another WIP patch (obsolete) — Splinter Review
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


11 years ago
Assignee: stanshebs → tglek

Comment 12

11 years ago
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.

Comment 13

11 years ago
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.

could you check that this patch doesn't break any of your stuff?
Attachment #325440 - Attachment is obsolete: true
Attachment #326725 - Attachment is obsolete: true
Attachment #327008 - Flags: review?(dmandelin)
Comment on attachment 327008 [details] [diff] [review]
C compat patch for Dehydra

My analyses work fine with it.
Attachment #327008 - Flags: review?(dmandelin) → review+


11 years ago
Depends on: 445135
Dehydra and treehydra are no longer maintained by Mozilla.
Closed: 6 years ago
Resolution: --- → WONTFIX


Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.