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

Status: RESOLVED WONTFIX

(Developer Infrastructure :: Source Code Analysis, enhancement)

Description

[Benjamin Smedberg]

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

[Stan Shebs]

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

[Stan Shebs]

Attachment: WIP patch for C support

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 3

[Kevin Tew]

Attachment: Use dlopen to remove hard symbol dependency

Comment 4

[Vlad Sukhoy]

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

[(dormant account)]

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

Comment 6

[Vlad Sukhoy]

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

Comment 7

[Kevin Tew]

(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

[Vlad Sukhoy]

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

[Stan Shebs]

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

Comment 10

[Kevin Tew]

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

Comment 11

[Stan Shebs]

Attachment: Another WIP patch

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.

Comment 12

[(dormant account)]

Attachment: minimal patch to get dehydra to do stuff in C

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.

Comment 13

[(dormant account)]

Attachment: C compat patch for Dehydra

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 14

[David Mandelin [:dmandelin]]

Comment on attachment 327008 [details] [diff] [review]
C compat patch for Dehydra

My analyses work fine with it.

Comment 15

[Joshua Cranmer [:jcranmer]]

Dehydra and treehydra are no longer maintained by Mozilla.