[GCC-XML] Function bodies

[William Rivet]

My intended use of function-body-dumping(as well as existing data 
dumping) is for data coupling metrics. I don't need to even know what 
the operations are, just if a given variable was read or written or 
modified. The rest of the analysis wold be outside of gccxml. Certainly 
this would not be useful in producing linkable code.

I'm still unclear of the concern here, that is, why producing 
"executable xml" should be treated different than producing x86 ELF 
object code. and it sounds like it was made clear that gccxml would be 
challenged if it went "too far". If I understand Daniel's  meaning, he 
and I might be looking for similar incomplete information?

Daniel J. Lauk wrote:

>Hi,
>
>I feel my code is approaching a state (i.e. with Brad's help I got the CMake 
>stuff and also the flag if bodys should be dumped to working state), where it 
>makes sense to address the organisational stuff, you wrote about. I'll 
>comment on it inline...
>
>  
>
>>>I hope, my code will make it into gccxml's CVS some day...
>>>      
>>>
>>[...]
>>In order for your code to be accepted the following criteria must be met:
>>
>>1.) We must be able to argue that the amount of information still falls
>>short of a linking layer.  Otherwise we have to specify that the output
>>is "GPLed" if the -fxml-body flag is used.  I'd prefer not to have this
>>confusion.
>>    
>>
>
>What information needs to be missing? I never wrote a linker (yet) so I'm not 
>sure from which point on the information is a valuable linking layer.
>The information I need for my thesis, is dependencies between functions, and I 
>felt like: if I already have to go through the bodies' code, I might as well 
>dump it on the way :-)
>
>  
>
>>2.) Please look at the DTD/schema generation code integrated into xml.c
>>(it is still under development).  Your dump code should be paired with
>>equivalent xml_document_* functions.
>>    
>>
>
>That's no problem, though I haven't started yet. I'll have to read up about 
>xml schema, but that's no big deal.
>
>  
>
>>3.) The code should be formatted and styled similar to that in xml.c.
>>    
>>
>
>Of course. I'm flexible on such topics. I think I could get a source 
>formatting tool, like lint or indent, to do the dirty work :-)
>
>  
>
>>4.) The style of the output XML should be in the spirit of the current
>>format.  Please send me sample input/output along the way and I'll comment.
>>    
>>
>
>I'll send you another mail with code and (incomplete) xml output.
>
>  
>
>>5.) There should be no code duplication (xml.h sounds good for this).
>>    
>>
>
>I realized, that I need quite a bunch of code, that is "static" in xml.c (e.g. 
>xml_add_node for obtaining functions' IDs). That means, that I modified the 
>prototype in xml.h and also the function header in xml.c. And then I 
>realized, that there are lots of those, and I probably would need them all 
>for a complete dump (there issue 1. comes into play again) ... so I guess, 
>I'd rather put xml.h back into xml.c (or leave it this way, never mind) and 
>incorporate my changes directly there.
>
>  
>
>>6.) You must be willing to distribute the code under the same terms as
>>xml.c is right now.  This means I will put the Kitware copyright on top
>>of the code, but I will leave whatever copyright you want intact under
>>it as long as the license is compatible.  This requirement is not meant
>>to take credit from you; your name will still appear in the original
>>copyright.  I just don't want to increase the complication of the
>>licensing.
>>    
>>
>
>Sure, no problem. As I mentioned earlier, the license I'd have chosen would've 
>been quite liberal anyway.
>
>I'm curious on your comments.
>
>Best regards,
>DJ
>_______________________________________________
>gccxml mailing list
>gccxml at gccxml.org
>http://www.gccxml.org/mailman/listinfo/gccxml
>
>  
>