introspector-developers Mailing List for RDF Software Introspector (Page 12)
Status: Beta
Brought to you by:
mdupont
Menu
▾
▴
introspector-developers — for anyone interested in hacking the introspector
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(1) |
Mar
|
Apr
(8) |
May
(6) |
Jun
(9) |
Jul
(6) |
Aug
(4) |
Sep
(2) |
Oct
(18) |
Nov
(29) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(57) |
Feb
(41) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(6) |
Jul
(3) |
Aug
(34) |
Sep
(28) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(3) |
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James M. D. <mdu...@ya...> - 2002-06-28 12:26:40
|
Please excuse this cross posting, I know that it is not very good manners. I had replied this morning only to the introspector-developers list, but since we have a cross-post here, then I will respond one last time to all. I would like ask the few if any who are interested in this discussion to reply only to the int...@li... list, because that way all the ideas are funneled into one spot. Everyone else, please excuse the wasting of bandwidth, just hit delete. :) David Sugar <dy...@os...> wrote: > However, all such efforts must be undertaken with an extreme measure > of caution. I aggree completly. For this reason, I am being carefull about what license and data is used untill we can reach an agreement. >I do encourage a great deal of review of the question and the legal >foundations of any specific license proposal before it is considered >for actual use. Yes %100. That is why I am not proposing a license just yet in conjunction, even if I have been thinking and writing about it. I dont want to get into a legal discussion with this mail and the gcc list does not want to be spammed with more legal questions. Let us just say that there is sensitive and non-sensitive data that should be treated with different levels of security. We should be able to explicitly mark such data as secure inside the given program and have it treated as such by the meta-data extractor tools. This making of private data with stricter licensing will be very important for the next generation of DotGNU web services. Authentication and ACLs will play a large role when programs just swim through the sea of servers collection needed information. Let me address this just on a technical level. Basically, the idea behind the introspector is that All types of data is stored about software on files in various formats, all types of programs exist to process this information. The idea behind the introspector is to extract that data out of the running tools via an XML Dumper patch into a common format (XML/RDF/DAML) and then have all types of tools to collate that into a repository of meta data. Instead of building tools to read the data, we change the existing GPled tools to tell us about the data. This could be harmless and very dangerous depending on the data involved, and a security concept is needed to regulate the proliferation of data. Remember in the old day, we had one executable, now we all have bandwidth, ram and disk with very little limit. This would then be presented back to the programmer, be accessable at run time and even the end user might benefit. The user will be able to use various tools like EMACS, DIA, VCG, MOZILLA, and more that are augmented to read and process this new unified data format. The interesting work being done on DAML fits perfectly into the meta-data and symantic repository concept. This introspection means that a program "knows" about itself and its environment, of course it is only possible and interesting for a user to process this information intelligently, the program is just a program that contains references to its meta data in a standard form. My current version contains a meta data framework in perl and a XML dumper for the gcc. The perl collects data from the gcc, stores the metadata in postgres repository , and then can do code generation in SQL, PERL, and XML. There is a lot of bits and bobs to the introspector, and now I am finally putting it all together. Also the first targets for the introspector were Perl, the gcc itself and the DOTGNU PNET C# compiler Cscc. I have the XML dumps of those projects metadata for a good point, that includes all public function decls, data types, modules and identifiers. For the sake of security and being social, the dumping of the full function bodies will be disabled for the standard build. The is what gets people upset because you can generate code with it. I propose that we define a standard interchange format for this meta data between the various free software development tools, this will be centered around a "HARD" typesafe shell (IDL/C/C++/Java/C#) API around a "SOFT" "XML/PERL/Python/Ruby/GUILE" scripting language, and SQL/XML/GDMB data repository with a XMLRPC/SOAP/CORBA/RPC network layer. Like the ActiveStates perlnet interface specification layer, you will be able to specify a typesafe interface into your scripting language using an IDL like language, and then generate via a standard set of tools an shell to contain your softer data. > BTW, would this follow the "Modest Proposal for a GNU infrastructure > license"? I did not reference that for a reason, to avoid more legal talk on a development list. I am not a laywer. Let my tell you about the technical side and give you a reference to how it was handled in the old days of the GCC development. The introspector in the spirit of the GNU manifesto, this proposal is radical and questions many of the existing currents in the GNU community. But it should be %100 GPL compatible. The only issue will be to devise the proper security model in terms of the DOTGNU framework. Some "DANGEROUS" data will not be published to the public, but only to a registered set of users across a secure interface. This is a problem that will be address on the DOTGNU list, not on the gcc list. This is like how the GCC development used to take place, where only the finished product was released. I you are interested in some history, check out this : "Re: what DOES the GPL really say?" thread. http://groups.google.com/groups?threadm=m2zpq0h7uc.fsf%40devo.ridgecrest.ca.us BEGIN LEGAL SECTION If we did something similar, we might have ability to distribute "Dangerous" patches to a select few via SSH and some TERMS of Usage and EULA agreement, I am not a lawyer, and the legal FAQ will be published in a few weeks. Even if the agreement says : "You can distribute this by the GPL, but if you do we will stop the service and publically state that you as the one who broke the aggreement". But again, I don't want to talk about licensing here. END LEGAL SECTION The modest proposal for a RGPL is a legal and social discussion, I want to avoid all futher license discussion on the development lists, if you are interested in it : my last update to the gnu.misc.discuss was here : http://groups.google.com/groups?threadm=aes5e7%24uk6%241%40quimby.gnus.org the thread on the FSL-dicuss here : http://lists.alt.org/pipermail/fsl-discuss/2002-June/000508.html And my blogger here: http://gccintrospector.blogspot.com/2002_06_23_gccintrospector_archive.html#78243629 Best regards, Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: David S. <dy...@os...> - 2002-06-28 12:02:44
|
I do happen to believe there may be places and situations where new licensing needs to be explored. For example we have the FDL for documentation, which has different issues to address than software, and there has been some efforts made to extend the GPL to be workable with web services where no code is "distributed" in the classical sense. However, all such efforts must be undertaken with an extreme measure of caution. The GPL itself is founded on a very solid and clever insight on copyright law that is unassailable. Many other licenses make the mistake of assuming how they think the law should operate rather than how it actually does. That is very easy trap to fall into and one we cannot afford to make in the GNU project. That being said, I do not discourage you at all from proposing a "GNU" or otherwise Free Software "infrastructure license", or to make a case why we may need such a seperate license, as it may well be that we might, but I do encourage a great deal of review of the question and the legal foundations of any specific license proposal before it is considered for actual use. S11001001 wrote: > Hate to admit it, but this is way over my head. It is highly probable > that the same goes for some lurkers here [on DotGNU], so....(insert > proper request here) > > BTW, would this follow the "Modest Proposal for a GNU infrastructure > license"? > |
|
From: James M. D. <mdu...@ya...> - 2002-06-28 07:22:47
|
I have taken this discussion to the introspector-devel list where it belongs. I dont want to bother the gcc group any more. --- S11001001 <ru...@si...> wrote: > Hate to admit it, but this is way over my head. It is highly probable > that the same goes for some lurkers here [on DotGNU], so....(insert > proper request here) Let me address this on a technical level. Basically, the idea behind the introspector is that All types of data is stored about software on files in various formats, all types of programs exist to process this information. The idea behind the introspector is to extract that data out of the running tools via an XML Dumper patch into a common format (XML/RDF/DAML) and then have all types of tools to collate that into a repository of meta data. Instead of building tools to read the data, we change the existing GPled tools to tell us about the data. This could be harmless and very dangerous depending on the data involved, and a security concept is needed to regulate the proliferation of data. Remember in the old day, we had one executable, now we all have bandwidth, ram and disk with very little limit. This would then be presented back to the programmer, be accessable at run time and even the end user might benefit. The user will be able to use various tools like EMACS, DIA, VCG, MOZILLA, and more that are augmented to read and process this new unified data format. The interesting work being done on DAML fits perfectly into the meta-data and symantic repository concept. This introspection means that a program "knows" about itself and its environment, of course it is only possible and interesting for a user to process this information intelligently, the program is just a program that contains references to its meta data in a standard form. My current version contains a meta data framework in perl and a XML dumper for the gcc. The perl collects data from the gcc, stores the metadata in postgres repository , and then can do code generation in SQL, PERL, and XML. There is a lot of bits and bobs to the introspector, and now I am finally putting it all together. Also the first targets for the introspector were Perl, the gcc itself and the DOTGNU PNET C# compiler Cscc. I have the XML dumps of those projects metadata for a good point, that includes all public function decls, data types, modules and identifiers. For the sake of security and being social, the dumping of the full function bodies will be disabled for the standard build. The is what gets people upset because you can generate code with it. I propose that we define a standard interchange format for this meta data between the various free software development tools, this will be centered around a "HARD" typesafe shell (IDL/C/C++/Java/C#) API around a "SOFT" "XML/PERL/Python/Ruby/GUILE" scripting language, and SQL/XML/GDMB data repository with a XMLRPC/SOAP/CORBA/RPC network layer. Like the ActiveStates perlnet interface specification layer, you will be able to specify a typesafe interface into your scripting language using an IDL like language, and then generate via a standard set of tools an shell to contain your softer data. > BTW, would this follow the "Modest Proposal for a GNU infrastructure > license"? I did not reference that for a reason, to avoid more legal talk on a development list. I am not a laywer. Let my tell you about the technical side and give you a reference to how it was handled in the old days of the GCC development. The introspector in the spirit of the GNU manifesto, this proposal is radical and questions many of the existing currents in the GNU community. But it should be %100 GPL compatible. The only issue will be to devise the proper security model in terms of the DOTGNU framework. Some "DANGEROUS" data will not be published to the public, but only to a registered set of users across a secure interface. This is a problem that will be address on the DOTGNU list, not on the gcc list. This is like how the GCC development used to take place, where only the finished product was released. I you are interested in some history, check out this : "Re: what DOES the GPL really say?" thread. http://groups.google.com/groups?threadm=m2zpq0h7uc.fsf%40devo.ridgecrest.ca.us If we did the say, we would have ability to distribute "Dangerous" patches to a select few via SSH and some TERMS of Usage and EULA agreement, I am not a lawyer, and the legal FAQ will be published in a few weeks. Even if the agreement says : "You can distribute this by the GPL, but if you do we will stop the service and publically state that you as the one who broke the aggreement". I dont want to talk about licensing here. The modest proposal for a RGPL is a legal and social discussion, I want to avoid all futher license discussion on the development lists, if you are interested in it : my last update to the gnu.misc.discuss was here : http://groups.google.com/groups?threadm=aes5e7%24uk6%241%40quimby.gnus.org the thread on the FSL-dicuss here : http://lists.alt.org/pipermail/fsl-discuss/2002-June/000508.html And my blogger here: http://gccintrospector.blogspot.com/2002_06_23_gccintrospector_archive.html#78243629 Best regards, Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: S11001001 <ru...@si...> - 2002-06-28 05:56:03
|
Hate to admit it, but this is way over my head. It is highly probable that the same goes for some lurkers here [on DotGNU], so....(insert proper request here) BTW, would this follow the "Modest Proposal for a GNU infrastructure license"? -- Stephen Compall DotGNU `Contributor' -- http://www.dotgnu.org The GNU GPL is not Mr. Nice Guy. It says "no" to some of the things that people sometimes want to do. -- RMS, "Copyleft: Pragmatic Idealism" |
|
From: James M. D. <mdu...@ya...> - 2002-06-27 21:16:10
|
Please Excuse this cross posting,
I propose the following API into free software development tools
to be licensed for the orderly, secure, fast, and high tech buzzword
compliant data backbone for a new gnu development environment.
ABSTRACT
The Introspector is a tool chain to extract meta-data about your
programs from the compiler and present it to you for making your job as
a programmer easier.
The software is free software in the spirit of the GNU manifesto and is
revolutionary in the freedoms that it intends on granting to its users.
There are many many licensing and legal issues addressed by this
project, and my guideline for resolving them are to limit the usage of
the tool for non-free software if there is a need to. The legal and
licensing FAQ will be posted in the next weeks.
This Meta-Data includes all data collected about your software by the
Compiler, the Make system, the Project and Packaging system,
the CVS Logs and the Mailling List.
The Introspector's scope was originally just the GCC C compiler, but
will be expanded to include the extraction of meta-data from different
compilers and interpreters.
The programs meta-data will be provided as a Perl/C#/(XML/RDF/DAML)/SQL
or plain old C/C++ interface.
We will build tools to allow this meta-data to be processed by various
GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA, and
Editors like EMACS.
Also Languge bindings like
compiling (gcc(C, C++, java) | cscc(CSHARP))
scripting (guile|Python|Perl { via inline::| }|Ruby)
reasoning (guile|scheme|lisp|prolog)
repository (GDBM|(POSTGRES|MYSQL)XIndice)
communication (soap|xmlrpc| + a newly development of a REST api)
This meta-data will be stored in a repository and available to tools
that need it via many different interfaces.
I look forward to your comments.
Please come visit my updated webpage at :
http://introspector.sf.net
You will find an copy of related snippets and news at :
the blogger : http://gccintrospector.blogspot.com
Best regards,
Mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
|
|
From: James M. D. <mdu...@ya...> - 2002-06-27 17:31:17
|
Dear All, I have updated the main web page and blogger. Please check them out. Next week on wednesday I will be meeting with richard stallman for a discussion about the gcc interface for the introspector. Please send me some feedback if you want to continue getting these emails, if you are interested at all in the project, or just dont care. regards, Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: James M. D. <mdu...@ya...> - 2002-06-06 06:58:03
|
Dear All, I am writing to you to try and drum up some activity for the introspector project. Over the past year we have had over 1000 downloads of the project releases. Many people have expressed interest in the project. I ask you to please join the list int...@li... for the futher discussion of these issues. You can do that by clicking on this link and adding yourself in. http://lists.sourceforge.net/lists/listinfo/introspector-developers I have started from scratch once again to create a specification for the software. The file formats, the modules, the processes. We will be wrting the spec in DOCBOOK but using a special specfication language like XMI that is xml based and very very simple and free form. You will find a first draft of the spec tar and GZ on http://prdownloads.sourceforge.net/introspector/introspector_dtd.tar.gz?download and the dtd on http://prdownloads.sourceforge.net/introspector/introspector_spec.tar.gz?download They are just the beginning of a new generation of the introspector. I hope that we will all submit our specifications to the list for different pieces of the project that we want to see. If we use an XML format for the specification language, then we can automatically process the specs to generate code later on. I hope to hear back from you with your ideas and questions, Best regards Mike ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Richard S. <rm...@gn...> - 2002-05-13 17:00:57
|
I believe this to be the case. Also, call graphs in C++ are much harder to
analyze, due to the complicated name lookup and overload resolution
semantics; to handle them in your browser, you basically need to implement
a large chunk of the C++ frontend. The obvious solution is to use the
pre-existing frontend.
I designed a way to make this approach handle preprocessor
conditionals usefully. Nobody has implemented it, though. It
requires preprocessor changes and front-end changes.
|
|
From: James M. D. <mdu...@ya...> - 2002-05-13 06:08:33
|
>You may want to involve yourself with one of the ongoing >UML projects and leverage your interests onto work >already started. Do you mean DIA, Argo-UML, Doxygen? Maybe Something else? There are many UML projects out there, I have not seen many free-software UML projects for the extraction of UML from C/C++. Mike ===== James Michael DuPont __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Jason M. <ja...@re...> - 2002-05-12 17:24:48
|
>>>>> "Richard" == Richard Stallman <rm...@gn...> writes: > This issue arises for call graphs in C code. C++ class structure is a > different issue. Perhaps people rarely use preprocessor conditionals > in ways that affect the class structure. If so, this issue would not > arise for that specific application. I believe this to be the case. Also, call graphs in C++ are much harder to analyze, due to the complicated name lookup and overload resolution semantics; to handle them in your browser, you basically need to implement a large chunk of the C++ frontend. The obvious solution is to use the pre-existing frontend. Jason |
|
From: Richard S. <rm...@gn...> - 2002-05-12 16:34:30
|
James wrote
You would like to extract the class structures of a
given program into UML, maybe into a XMI like data
format?
Praveen, could you tell me more precisely what job you want to do?
Do you want to record just the class structure, or something more?
I see no problem of abuse in making cc1 record information on the
class structure. The question is purely a technical one, as long
as that is as far as the feature goes.
In general, using output from GCC's parse phase to record
cross-reference information is a flawed technique because it does not
understand preprocessor conditionals. If your code says
foo ()
{
#if defined (__gnu__) || defined (__unix__)
foo_1 ();
#else
foo_2 ();
#endif
}
then a cross reference meant to help a human understand the program
should say that foo calls both foo_1 and foo_2. However, a cross
reference generated in the straightforward way from inside a compiler
would mention only one of them.
This issue arises for call graphs in C code. C++ class structure is a
different issue. Perhaps people rarely use preprocessor conditionals
in ways that affect the class structure. If so, this issue would not
arise for that specific application.
However, the Emacs OOBR already has the ability to analyze the class
structure of a program and then browse it. Does it already do what
you want?
|
|
From: James M. D. <mdu...@ya...> - 2002-05-10 14:23:07
|
Praveen, Since no-one has answered your mail yet, I will attempt to. Note that this is just my personal opinion on this matter and in no way does it speak for rest of the gcc community. This being my favorite topic, I will explain the background on this topic and use my answer to present some of ideas on this topic to you and to the gcc mailing list. >>I'm currently trying to make a tool that'll generate >>UML specs from c++ code. I understand your motivation for this request and I have been thinking about similar things myself. I too have been sold on the idea of UML and having nice diagrams of my code. "How come we cannot extract this data from the GCC?" was my the motivating question over 8 years ago. You would like to extract the class structures of a given program into UML, maybe into a XMI like data format? see : http://xml.coverpages.org/xmi.html Like many of the UML tools listed here?: http://directory.google.com/Top/Computers/Programming/Methodologies/Object-Oriented/UML/Tools/?tc=1 That type of extraction or at least the visualization is one of the one of the goals of the introspector project that I started. The problem is that my project is that XML/SQL or *any* intermediate representation of gcc tree structures is a file is not secure enough to prevent abuse of the gcc. Therefore I have started a re-design to cover many new aspects. http://introspector.sourceforge.net. Currently, I am busy re-designing the project to eliminating all xml and sql external data to remove the possibility of third-party abuse of the data and circumvention of the GPL. In my humble opinion, In the long term, an UML like GUI and class browser will be possible to be linked directly into the gcc and the various aspects of programs can be visualized. You should understand that the pure extraction of such information by the gcc to feed to case tools like rational rose and together++ via XMI might not be in the best interests of the GCC/GNU/FSF community. The extraction of compiler data about data structures and feeding them to non-free software like GraphVis/Rational Rose/ TogetherC++ and others does not benefit the free software, but more takes the wind out of the sails of an effort to create free replacements for such tools. One of the difficulties that we are presented with creating case tools with the GCC has is the issue of the usage of the "internal data str." the tree structures. >>I am searching for a library version of GNU's C++ >>front end , and documentation on its interface >>(through which I can query its internal data str.) That library is the core gcc compiler, the tree structures that are connected with the c/c++ language front ends. Now in order for you to create such a tool you will have to create a modified version of the gcc, one that produces the UML, maybe in XMI format. This type of interface would also allow for all types of information to be extracted from the gcc. One of the issues involved here is the licensing of such a tool, it would have to be a GPL licensed tool. The other issue is that of the extracted data, are you interested in extracting just static data structures, or also dynamic UML structures, so that you would also like to see the run-time behavior of the program at hand? Then you will need to extract also the function bodies, and from that UML representation, you could create a brand-new re-factored program. That is of course a very tempting idea and the basis of many of the tools like together++ and rational rose. There is also a tool the provides such a function for java written in java called argo-uml, that includes a Java parser. There is also a tool called DIA that has support for UML diagrams. In the end both tools could be used for a display mechanism, argo-uml is much further along than Dia, but DIA is written in C/C++ and would be easier to use as an add on to the gcc. The other question of graph layout can be tackled by a tool called VCG. That has some good graph layout algorithms, but is GUI is way out of date. Those two tools (DIA and VCG), coupled together with the gcc, statically linked into one program, could serve as the basis for a C++/UML based code browser using the gcc. If you are only interested in only the static structure of c++ functions and classes you might be able to use the xml output from the gcc_xml. http://www.gccxml.org >>Could you please guide me to the correct library and >>where I could download it ? The gcc parsers and code generators are not distributed as libraries for linking into. If you want to create a gcc module, you should create a statically linked program that uses the data needed. >>I explored the links on the gcc pages but could not >>locate these. It is one of the lesser documented and published areas of the gcc. The new chapter 18 of the gcc manual contains a good overview of tree structure. http://gcc.gnu.org/onlinedocs/gccint/Tree-overview.html I would suggest that you define exactly your statement of the how you would like to represent and display the UML. Also you should be willing to put all of your changes and programs under the GPL and not try and export data to non-gpled programs. Doing that will give you the best basis for such an endeavor. It will be a difficult endeavor and a rocky, uphill battle, but I think it will be worth it. Mike ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com |
|
From: James M. D. <mdu...@ya...> - 2002-05-06 17:25:58
|
Sebastien, Brad and other list members, Let me answer some of your questions about the introspector, a related project to the gcc_xml that I have been working on for the past some time on my free time. Note that what follows is a long post about the history and development of the introspector, so please ignore it if you are not interested, but I also attempt to answer sebastiens questions as well. >> - What is the link with http://introspector.sourceforge.net/, if any ? The introspector and gcc-xml projects are similar, but not exactly the same. Originally I was working for a company Innovative software GmbH that was creating a C++ reverse engineering program, it could display class tree, relationships, modify and generate code. Like rational rose to together++. I had always thought about why they did not use the gcc for parsing, it was much better. The company had stopped working on and selling the product, and there were no free software tools to do the exact same. (Maybe argo-uml for java, but not for c and c++) At the time I did not understand the tree structures well enough to be able to create such an interface. Four years into my new job, I started on a different track with the beginnings of the introspector project, in 1999 to create a OO C++ interface into the compiler tree structures. Brad had been posting some ideas about using XML for dumping in the summer of 2000 about using XML for output. His main intention (Correct me if I am wrong brad ) was to get at the function and type declarations for creating better wrapper libraries for gcc. My intention is to create a better user API into the gcc compiler. The toolkits of kitware benifit greatly from having properly typed language wrappers, better than swig. A long time had passed, and I was busy working on my c++ interface and building in some form of debugging output to understand the tree structures. At the OOP 2000 Conference in Munich, I was inspired by to use XML and liked the idea of the intentional programming that was being research by microsoft at the time. Afterwards I decided to put my efforts into a XML exchange format. No easy task. After fighting with my non understanding of the compilers tree structures and preparation for my talk about the introspector at the YAPC::Europe, I stumbled over the cppxml from the university of waterloo, they modified the tree-dumper function of the gcc compiler and used some transformations on the trees. I took the tree dumper and modified it to output xml. that was the basis for my xml interface into the gcc. First I wanted to use DSSL to process the XML, and started to learn scheme. The problem was that I could not interact with the dssl enough to learn it, I like some form of interactive tool to learn a language. XSLT was better documented than DSSSL, and I got some reports running in it. XSLT is not a good language for processing ASTs because they are highly networked, you need to be able to go in any direction, and XSLT is not efficient at that. Prolog was my next choice, but the memory limitations of the gnu-prolog stopped me from doing more that 30000 nodes at onces. After using xslt to translate the structures into prolog in order to query them, I discovered the main structure of the tree structures. This understanding led me to translate the xml into perl programs, that when run would construct the tree structures in memory without using an XML Parser. I had abandoned my c++ interface for a perl interface and started to write reports and code generators in perl. Afterwards I removed the XSLT and replaced it with a XML parser. Later I put the perl program in a pipe from the compiler, so that you can pipe the results from the compiler directly into perl. I have built an Postgres and Mysql repository of the tree structures and have written hundreds of queries that have shown me how the tree nodes work properly. Now in the past 3 months, I have been in contact with the FSF about getting support for my project. Currently we are in discussions to prevent the abuse of the XML and external data by third partys. The issue is to prevent the usage of the gcc by non-free software in such a way that they can piggyback on top of it. The introspector gives such a security hole in its current incarnation and has to be changed. My intent is to remove *ALL* forms of XML, SQL and external data until an updated version GPL of the GPL will come out to prevent the usage of that data in non-free software. I would be very careful if you intend on using the GCC internal data in any form of non-free, non-gpl software. You might be opening yourself up too a violation of the GPL. Especially if you have to redistribute the gcc and its only purpose of that redistribution and modification is to extract that data into a non-free software. Currently I am working on linking GCC directly to perl. Then all the needed data can be extracted directly from the compiler. My intent is also to link in a GUI directly into the whole thing, and remove any data files that need to be exchanged. Sebastien, As to transformations on code that you are interested in doing, I think that the best and safest bet would be to create a compiler extension to do that, you can then have your own code that will do tree transformations to do that inside of the compiler. See the Ast-optimizer branch for that. In the future, the introspector might make it easier to do such a thing, but you will need to be willing make your modifications GPLed for me to help you out. >>- is there a xml -> gcc front-end already built ? No, and I think that it is not wished for, that would make it too easy for abuse. >> - is it possible to introduce some "new macros" >>constructions in C/C++ that gccxml will leave >>untouched and that could be interpreted on an XML >>processor ? I think that you would be best off by declaring a special type, let's say FunkyPointer<T> that you can used to declare extra information in your program. Or if you want to add attributes, a template would be good. HelpName<T,"STRING"> can be extracted easily from inside the compiler. So if you have float, HelpName<float,"A float is a floating point number"> that would add extra attribute to your program, the xml of gcc_xml could be used to then scanned for such instances and they could be extracted and processed. >>As XML is real close to Lisp/Scheme way of thinking >>(list processing) and that Lisp/Scheme macros are >>much more powerful (expressive), I think this >>approach can be interesting. That is similar to the XSLT work i was doing. Anyway, I hope that this all presents some insight into the purpose of the introspector and its relationship to the gcc_xml. And again, I can only hope that you can for yourselves resolve the licensing issues with the FSF. I know that brad had written to them, but I would consider also warning your users that the licensing is an issue, and tell them to consider GPLing all code that uses the AST information even indirectly from the GCC. Just for the record, I see the gcc_xml project and cabel as being valuable tools. I don't think that they are abusing the GPL directly, but my opinion does not matter much. You have to make sure that your users understand the possibilities of a GPL violation. Mike ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: James M. D. <mdu...@ya...> - 2002-04-22 11:05:55
|
Hello Everyone, I was quite surprised to see how many people are subscribed. If I knew that, I would have written more to you. If you have taken the time to subscribe, please take the time to introduce yourself. Name, Rank and Serial number. Has anyone tested the code, what is your interest in the introspector, what have you done in that area? Here is my short intro : My name is James Michael(mike) DuPont, I am employed by MCI Worldcom in Germany as a software developer. On my free time I am hacking away at the gcc compiler under linux. Currently I am working on a new package framework with CPAN/Debian and RPM Modules. Also I am trying to get approval for the introspector as an official GNU supported project. Does anyone of you plan on using the introspector in a non-free closed source application, if so, we have to talk..... Mike ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-20 08:08:07
|
Hello Taiq, I will forward my reponse to the maillist list. Currently I cannot add anyone to the mailling list! > How goes it on this Friday night? Good, it is Saturday morning in germany. > link that you sent me but still have yet to look at > it. i will give it a gander though. It is coming along, working on it every day. You run linux? > Reverse Engineering: To be honest, i do not have any > experience with this area nor do i have a lot of > knowledge about it and what it is exactly. Reverse Engineering is the extraction of information from an existing program, source code or executables. The creation of a new sortware given an existing program as an input. > > i am however, very interested in XML development > especially when it involves other technologies, for > example your current project. Yes, XML is central to the introspector. The GCC compiler is modified to output XML. The XML is streamed to a perl program that can process it, It puts the xml records in a database. Currently I am working on front ends to this database and scripts to run the compiler. > i do not know what, if anything or in any manner, i > could be a part of this project but it would be nice > to work on something of this nature. If you are interested in on of the following : 1. producing HTML pages from XML? 2. producing file format converter to other XML formats? 3. testing 3.1 setting up test cases 3.1 running tests documenting errors 4. documenting Creating web pages using on of the following : 1. Writing XSLT programs - some of that. 2. Writing perl programs - LOTS of that. 3. Writing php programs - i have no skill here 4. Writing java programs - I have started on java clasess, need testing. 5. Writing SQL queries - we need more of them. >i look forward > to hearing more about the project status and its > lifecycle. The database is ready for usage The perl database access is usable. The program to run the compiler is usable. Mike > --- James Michael DuPont <mdu...@ya...> > wrote: > > Hey, > > > > I am sorry that I have not gotten you subscribed > > yet. > > Anyway, you are the only one on the list so far! > > > > Currently I am working on a mysql port of the > > simplified database model. > > > > If you are interested, here is a self-contained > > mysql database script. > > > http://introspector.sourceforge.net/dotgnu/introspector_mysql.tgz > > > > Please tell me about your interest and experience > in > > the area of reverese engineering? What brought you > > to > > my project webpage? > > > > mike > > > > > > > > ===== > > James Michael DuPont > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Tax Center - online filing with TurboTax > > http://taxes.yahoo.com/ > > > ===== > <m.nelson /> > Web Developer > More sacrifice, > creates better living. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Games - play chess, backgammon, pool and more > http://games.yahoo.com/ ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-19 20:43:45
|
Dear DOT Gnuers, I have setup a mysql database on my machine and on the sourceforge server for the introspector database, and loaded the SQL for the DOTGNU project that I created for you. If anyone is interested in writing queries or using the server you have to setup a sourceforge account and then you can access the server. Also if you are interested, here is a self-contained mysql database script. It contains the entire database creation and the ccsc compiler code tree structure inside the simplified introspector database mode. http://introspector.sourceforge.net/dotgnu/introspector_mysql.tgz I will be porting my perl scripts to use the mysql, maybe anyone has an Idea on how to setup a xmlrpc server to proxy the database server? The best would be a simple command line interface to run queries and a Jabber link to route the queries to and from the server. With this interface anyone can run an introspector client that has a net connection and get access to the meta-data of the pnet system without having to load all the meta-data into the system. The entire pnet system would be GBs of data, and could be mirrored across many servers! Even a command line perl script using jabber::net could be used, but what about the server side? How hard is it to set-up a jabber server. Mike --- James Michael DuPont <mdu...@ya...> wrote: > Dear Fellow DotGNUers, > > I have done the first step in actually *Doing* > something for DotGNU and towards a bridge between > the > gcc and pnet and not just thinking and talking > about > what I want to do all the time. > > Taking the csnodes.c and running it through the > introspector for one. Tweaking and *SIMPLIFING* the > database model so that you can probably run in on > *ANY* sql database server. Putting it all on a > server > that you can download and play with. > Sorry that the last release from me did not have any > documentation or tips on how to use it. One has to > be > carefull, the asts are very BIG and hard to use. But > we will get there :=) > > I have reduced the database mode down to 3 tables > > *node_base > contains the ID and the type of the node > > *node_attr > contains the ID of the node, type and value of > the > attribute. > > *node_usage > contains the fromid, toid , types of nodes and > type > of relationship > > With these three tables you have a full graph of the > parse tree of the c# compilers node structure. > > The SQL for the tables is located on > http://introspector.sourceforge.net/dotgnu/simple.sql > > The data for inserting into the database you will > find > in a gz sql file here : > http://introspector.sourceforge.net/dotgnu/____global.xml.sql.gz > > The XML that was dumped you will find here : > http://introspector.sourceforge.net/dotgnu/____global.xml.gz > (If you are interested in parsing the XML yourself ) > The XML has the following structure: > > <xmlroot> # the root of the document > > # tells you what file that was compiled to get these > nodes > <xml_cfile name= NAME OF SOURCE FILE/> > > # each tree node in the parse tree produces such > a > xml entry > <node idx=NUMBER OF NODE > node_name=TYPE OF NODE > > > # RELATIONSHIPS - each relation to a different > node is contained inside of the NODE element > < # EACH RELATION is an entity of one of > the following types > name | type | unql | size | min | max | args > | > prms | scpe | flds | body | chan | valu | > op_0 | op_2 | val | purp | next > > > idx="THE ID OF THE OTHER NODE" > ref_node_name="THE TYPE OF OTHER NODE TYPE" > /> > > # ATTRIBUTES SOME of the following attributes > might be set : > <strg>THE VALUE OF A STRING</strg> > <srcl>SOURCE LINE</srcl> > <srcp>SOURCE FILE</srcp> > <prec>PRECISION</prec> > <algn>ALIGNMENT</algn> > <built_in>ALIGNMENT</built_in> > <low>LOW BYTE of a Constant</low> > <high>LOW BYTE of a Constant</high> > <lngth>Length of a string</lngth> > <qualconst>is const</qualconst> > <qualrest>?forgot for now :(</qualrest> > <qualvol>is volitile</qualcol> > <str>SOME TYPE OF PARAMETER FOR THE NODE (extern > for functions, struct for records)</str> > > </node> > # MANY OTHER NODEs may follow > </xmlroot> > > I am also testing a simple query language for > accessing the nodes. more about that next time. > > The files are located here : > http://introspector.sourceforge.net/dotgnu/ > > I hope that you can use these files and find them > helpfull. Next step is to create a cross reference > table between the GCC and the CSCC cores. > > Following are two example queries that show you the > power of the database. > > Mike > > First is a list of all the identifiers of > record_types > who name begin with IL > introspector_simple=# > > select distinct > value > from > node_usage u, > node_attr a , > node_base b > where > a.attr_type = 'strg' and > a.value like '"IL%' > and a.id=b.id > and u.to_id = b.id > and u.usage = 'name' > and u.from_type = 'record_type'; > > value > ---------------------------------------- > "ILNode_AddressOf__" > "ILNode_AddressOf_vtable__" > "ILNode_ArrayAccess__" > "ILNode_ArrayAccess_vtable__" > "ILNode_ArrayInit__" > "ILNode_ArrayInit_vtable__" > "ILNode_AsIs__" > "ILNode_AsIs_vtable__" > "ILNode_Assign__" > "ILNode_Assign_vtable__" > "ILNode_AttrArgs__" > "ILNode_BaseAccess__" > "ILNode_BaseAccess_vtable__" > "ILNode_BaseElement__" > "ILNode_BaseElement_vtable__" > "ILNode_BinaryArith__" > "ILNode_BinaryArith_vtable__" > "ILNode_BinaryBitwise__" > "ILNode_BinaryBitwise_vtable__" > "ILNode_BinaryExpression_vtable__" > "ILNode_BinaryShift__" > "ILNode_BinaryShift_vtable__" > "ILNode_CastSimple__" > "ILNode_CastSimple_vtable__" > "ILNode_CastType__" > "ILNode_CastType_vtable__" > "ILNode_Concat__" > "ILNode_Concat_vtable__" > "ILNode_Constant__" > "ILNode_Constant_vtable__" > "ILNode_DecimalType__" > "ILNode_DerefField__" > "ILNode_DerefField_vtable__" > "ILNode_Deref__" > "ILNode_Deref_vtable__" > "ILNode_DocComment__" > "ILNode_DocComment_vtable__" > "ILNode_DummyBinaryExpr__" > "ILNode_DummyBinaryExpr_vtable__" > "ILNode_DummySem_vtable__" > "ILNode_DummyUnaryExpr__" > "ILNode_DummyUnaryExpr_vtable__" > "ILNode_Dummy_vtable__" > "ILNode_Expression_vtable__" > "ILNode_FixAddress__" > "ILNode_FixAddress_vtable__" > "ILNode_FixExpr__" > "ILNode_FixExpr_vtable__" > "ILNode_FixedDeclList_vtable__" > "ILNode_Identifier__" > "ILNode_Identifier_vtable__" > "ILNode_IndexerAccess__" > "ILNode_IndexerAccess_vtable__" > "ILNode_IsNonNull__" > "ILNode_IsNonNull_vtable__" > "ILNode_IsNull__" > "ILNode_IsNull_vtable__" > "ILNode_LValueBinaryExpr_vtable__" > "ILNode_LValueNoRefUnaryExpr__" > "ILNode_LValueNoRefUnaryExpr_vtable__" > "ILNode_LValueNoRef_vtable__" > "ILNode_LValueUnaryExpr_vtable__" > "ILNode_LValue__" > "ILNode_LValue_vtable__" > "ILNode_List_vtable__" > "ILNode_LocalVariableType__" > === message truncated === ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-18 22:57:43
|
Dear Sirs, Please excuse the follwing cross posting. I know that it is frowned apon, but I hope that you find the following mail interesting. Originally it was meant for the dotGNU mailing list, but I think that it is of relevance to this list. Please come and join the int...@so... mailing list for a open discussion about creating an GPLD/Free-Software reverse engineering and program understanding toolchain. Mike --- James Michael DuPont <mdu...@ya...> wrote: > From: James Michael DuPont <mdu...@ya...> > To: dev...@do... > CC: int...@so..., > gvo...@vo... > Subject: [Introspector-developers] Example SQL and > XML of DOTGNU/CSCC/csnodes.c > Date: Thu, 18 Apr 2002 15:24:34 -0700 (PDT) > > Dear Fellow DotGNUers, > > I have done the first step in actually *Doing* > something for DotGNU and towards a bridge between > the > gcc and pnet and not just thinking and talking > about > what I want to do all the time. > > Taking the csnodes.c and running it through the > introspector for one. Tweaking and *SIMPLIFING* the > database model so that you can probably run in on > *ANY* sql database server. Putting it all on a > server > that you can download and play with. > Sorry that the last release from me did not have any > documentation or tips on how to use it. One has to > be > carefull, the asts are very BIG and hard to use. But > we will get there :=) > > I have reduced the database mode down to 3 tables > > *node_base > contains the ID and the type of the node > > *node_attr > contains the ID of the node, type and value of > the > attribute. > > *node_usage > contains the fromid, toid , types of nodes and > type > of relationship > > With these three tables you have a full graph of the > parse tree of the c# compilers node structure. > > The SQL for the tables is located on > http://introspector.sourceforge.net/dotgnu/simple.sql > > The data for inserting into the database you will > find > in a gz sql file here : > http://introspector.sourceforge.net/dotgnu/____global.xml.sql.gz > > The XML that was dumped you will find here : > http://introspector.sourceforge.net/dotgnu/____global.xml.gz > (If you are interested in parsing the XML yourself ) > The XML has the following structure: > > <xmlroot> # the root of the document > > # tells you what file that was compiled to get these > nodes > <xml_cfile name= NAME OF SOURCE FILE/> > > # each tree node in the parse tree produces such > a > xml entry > <node idx=NUMBER OF NODE > node_name=TYPE OF NODE > > > # RELATIONSHIPS - each relation to a different > node is contained inside of the NODE element > < # EACH RELATION is an entity of one of > the following types > name | type | unql | size | min | max | args > | > prms | scpe | flds | body | chan | valu | > op_0 | op_2 | val | purp | next > > > idx="THE ID OF THE OTHER NODE" > ref_node_name="THE TYPE OF OTHER NODE TYPE" > /> > > # ATTRIBUTES SOME of the following attributes > might be set : > <strg>THE VALUE OF A STRING</strg> > <srcl>SOURCE LINE</srcl> > <srcp>SOURCE FILE</srcp> > <prec>PRECISION</prec> > <algn>ALIGNMENT</algn> > <built_in>ALIGNMENT</built_in> > <low>LOW BYTE of a Constant</low> > <high>LOW BYTE of a Constant</high> > <lngth>Length of a string</lngth> > <qualconst>is const</qualconst> > <qualrest>?forgot for now :(</qualrest> > <qualvol>is volitile</qualcol> > <str>SOME TYPE OF PARAMETER FOR THE NODE (extern > for functions, struct for records)</str> > > </node> > # MANY OTHER NODEs may follow > </xmlroot> > > I am also testing a simple query language for > accessing the nodes. more about that next time. > > The files are located here : > http://introspector.sourceforge.net/dotgnu/ > > I hope that you can use these files and find them > helpfull. Next step is to create a cross reference > table between the GCC and the CSCC cores. > > Following are two example queries that show you the > power of the database. > > Mike > > First is a list of all the identifiers of > record_types > who name begin with IL > introspector_simple=# > > select distinct > value > from > node_usage u, > node_attr a , > node_base b > where > a.attr_type = 'strg' and > a.value like '"IL%' > and a.id=b.id > and u.to_id = b.id > and u.usage = 'name' > and u.from_type = 'record_type'; > > value > ---------------------------------------- > "ILNode_AddressOf__" > "ILNode_AddressOf_vtable__" > "ILNode_ArrayAccess__" > "ILNode_ArrayAccess_vtable__" > "ILNode_ArrayInit__" > "ILNode_ArrayInit_vtable__" > "ILNode_AsIs__" > "ILNode_AsIs_vtable__" > "ILNode_Assign__" > "ILNode_Assign_vtable__" > "ILNode_AttrArgs__" > "ILNode_BaseAccess__" > "ILNode_BaseAccess_vtable__" > "ILNode_BaseElement__" > "ILNode_BaseElement_vtable__" > "ILNode_BinaryArith__" > "ILNode_BinaryArith_vtable__" > "ILNode_BinaryBitwise__" > "ILNode_BinaryBitwise_vtable__" > "ILNode_BinaryExpression_vtable__" > "ILNode_BinaryShift__" > "ILNode_BinaryShift_vtable__" > "ILNode_CastSimple__" > "ILNode_CastSimple_vtable__" > "ILNode_CastType__" > "ILNode_CastType_vtable__" > "ILNode_Concat__" > "ILNode_Concat_vtable__" > "ILNode_Constant__" > "ILNode_Constant_vtable__" > "ILNode_DecimalType__" > "ILNode_DerefField__" > "ILNode_DerefField_vtable__" > "ILNode_Deref__" > "ILNode_Deref_vtable__" > "ILNode_DocComment__" > "ILNode_DocComment_vtable__" > "ILNode_DummyBinaryExpr__" > "ILNode_DummyBinaryExpr_vtable__" > "ILNode_DummySem_vtable__" > "ILNode_DummyUnaryExpr__" > "ILNode_DummyUnaryExpr_vtable__" > "ILNode_Dummy_vtable__" > "ILNode_Expression_vtable__" > "ILNode_FixAddress__" > "ILNode_FixAddress_vtable__" > "ILNode_FixExpr__" > "ILNode_FixExpr_vtable__" > "ILNode_FixedDeclList_vtable__" > "ILNode_Identifier__" > "ILNode_Identifier_vtable__" > "ILNode_IndexerAccess__" > "ILNode_IndexerAccess_vtable__" > "ILNode_IsNonNull__" > "ILNode_IsNonNull_vtable__" > "ILNode_IsNull__" > "ILNode_IsNull_vtable__" > "ILNode_LValueBinaryExpr_vtable__" > "ILNode_LValueNoRefUnaryExpr__" > "ILNode_LValueNoRefUnaryExpr_vtable__" > "ILNode_LValueNoRef_vtable__" > "ILNode_LValueUnaryExpr_vtable__" > "ILNode_LValue__" > "ILNode_LValue_vtable__" > "ILNode_List_vtable__" > "ILNode_LocalVariableType__" > "ILNode_LocalVariableType_vtable__" > "ILNode_LogicalAnd__" > "ILNode_LogicalAnd_vtable__" > "ILNode_LogicalNot__" > "ILNode_LogicalNot_vtable__" > "ILNode_LogicalOr__" > "ILNode_LogicalOr_vtable__" > "ILNode_MemberAccess__" > "ILNode_MemberAccess_vtable__" > "ILNode_MemberField__" > "ILNode_MemberField_vtable__" > "ILNode_MemberProperty__" > "ILNode_MemberProperty_vtable__" > "ILNode_NamedArg__" > "ILNode_NamedArg_vtable__" > "ILNode_Namespace__" > "ILNode_Namespace_vtable__" > "ILNode_Neg__" > "ILNode_Neg_vtable__" > "ILNode_NoOverflow__" > "ILNode_NoOverflow_vtable__" > "ILNode_NoPedantic__" > "ILNode_NoPedantic_vtable__" > "ILNode_Overflow__" > "ILNode_Overflow_vtable__" > "ILNode_Pedantic__" > "ILNode_Pedantic_vtable__" > "ILNode_PostDec__" > "ILNode_PostDec_vtable__" > "ILNode_PostInc__" > "ILNode_PostInc_vtable__" > "ILNode_PreDec__" > "ILNode_PreDec_vtable__" > "ILNode_PreInc__" > "ILNode_PreInc_vtable__" > "ILNode_QualIdent__" > "ILNode_QualIdent_vtable__" > "ILNode_Relational__" > "ILNode_Relational_vtable__" > "ILNode_Statement__" > "ILNode_Statement_vtable__" > "ILNode_StaticField__" > "ILNode_StaticProperty__" > "ILNode_StaticProperty_vtable__" > "ILNode_ToBool__" > "ILNode_ToBool_vtable__" > "ILNode_ToConst__" > "ILNode_ToConst_vtable__" > "ILNode_TypeSuffix__" > "ILNode_TypeSuffix_vtable__" > "ILNode_UnaryExpression_vtable__" > "ILNode_Unsafe__" > "ILNode_Unsafe_vtable__" > "ILNode_UserBinaryOp__" > "ILNode_UserBinaryOp_vtable__" > "ILNode_UserConversion__" > "ILNode_UserConversion_vtable__" > "ILNode_UserIncOrDec__" > "ILNode_UserIncOrDec_vtable__" > "ILNode_UserLogical__" > "ILNode_UserLogical_vtable__" > "ILNode_UserPostDec__" > "ILNode_UserPostDec_vtable__" > "ILNode_UserPostInc__" > "ILNode_UserPostInc_vtable__" > "ILNode_UserPreDec__" > "ILNode_UserPreDec_vtable__" > "ILNode_UserPreInc__" > "ILNode_UserPreInc_vtable__" > "ILNode_UserUnaryOp__" > "ILNode_UsingAlias__" > "ILNode_UsingAlias_vtable__" > "ILNode_UsingNamespace__" > "ILNode_UsingNamespace_vtable__" > "ILNode__" > "ILNode_vtable__" > > > Following is an example query that shows you what > type > of nodes point to what other types of nodes in the > current data set (It is loading right now, so not > finished yet). As you can see there is a lot of > information about the tree nodes as records and > fields. 1020 fields in the database, not bad! > > introspector_simple# select > from_type,to_type,usage,count(*) from node_usage > group > by from_type,to_type,usage order by count(*) desc; > from_type | to_type | usage | count > ---------------+-----------------+-------+------- > field_decl | identifier_node | name | 1020 > field_decl | integer_cst | size | 1020 > field_decl | record_type | scpe | 1007 > field_decl | field_decl | chan | 917 > field_decl | pointer_type | type | 754 > tree_list | tree_list | chan | 737 > function_decl | function_type | type | 512 > function_decl | identifier_node | name | 512 > tree_list | pointer_type | valu | 495 > function_decl | function_decl | chan | 485 > type_decl | type_decl | chan | 345 > function_type | integer_cst | size | 322 > function_type | tree_list | prms | 319 > record_type | field_decl | flds | 265 > record_type | integer_cst | size | 265 > tree_list | void_type | valu | 260 > type_decl | identifier_node | name | 258 > field_decl | integer_type | type | 229 > type_decl | record_type | type | 207 > integer_cst | integer_type | type | 193 > record_type | identifier_node | name | 182 > pointer_type | integer_cst | size | 165 > record_type | record_type | unql | 152 > tree_list | integer_type | valu | 152 > integer_type | integer_cst | max | 140 > integer_type | integer_cst | min | 140 > integer_type | integer_cst | size | 140 > function_type | integer_type | retn | 133 > type_decl | integer_type | type | 129 > integer_type | type_decl | name | 121 > integer_type | integer_type | unql | 106 > pointer_type | record_type | ptd | 105 > record_type | type_decl | name | 103 > function_type | pointer_type | retn | 91 > var_decl | identifier_node | name | 78 > function_type | void_type | retn | 71 > var_decl | integer_cst | size | 71 > var_decl | var_decl | chan | 69 > const_decl | enumeral_type | type | 65 > const_decl | identifier_node | name | 65 > tree_list | identifier_node | purp | 64 > tree_list | integer_cst | valu | 64 > const_decl | const_decl | chan | 60 > var_decl | integer_type | type | 44 > pointer_type | integer_type | ptd | 26 > type_decl | function_decl | chan | 24 > var_decl | pointer_type | type | 24 > function_decl | type_decl | chan | 19 > tree_list | enumeral_type | valu | 19 > pointer_type | pointer_type | unql | 18 > pointer_type | function_type | ptd | 17 > field_decl | union_type | scpe | 13 > tree_list | real_type | valu | 13 > field_decl | enumeral_type | type | 12 > function_type | real_type | retn | 12 > enumeral_type | integer_cst | max | 11 > enumeral_type | integer_cst | min | 11 > enumeral_type | integer_cst | size | 11 > enumeral_type | tree_list | csts | 11 > field_decl | record_type | type | 11 > parm_decl | function_decl | scpe | 11 > parm_decl | identifier_node | name | 11 > parm_decl | integer_cst | size | 11 > type_decl | enumeral_type | type | 11 > array_type | integer_cst | size | 9 > array_type | integer_type | domn | 9 > field_decl | array_type | type | 9 > pointer_type | type_decl | name | 9 > type_decl | pointer_type | type | 9 > array_type | integer_type | elts | 8 > complex_type | integer_cst | size | 8 > complex_type | type_decl | name | 8 > function_decl | parm_decl | args | 8 > function_decl | var_decl | chan | 8 > function_type | record_type | retn | 8 > pointer_type | void_type | ptd | 8 > type_decl | complex_type | type | 8 > parm_decl | pointer_type | argt | 7 > parm_decl | pointer_type | type | 7 > pointer_type | pointer_type | ptd | 7 > type_decl | real_type | type | 7 > var_decl | function_decl | chan | 7 > enumeral_type | enumeral_type | unql | 6 > enumeral_type | type_decl | name | 6 > real_type | integer_cst | size | 6 > real_type | type_decl | name | 6 > tree_list | complex_type | valu | 6 > type_decl | const_decl | chan | 6 > var_decl | array_type | type | 6 > const_decl | type_decl | chan | 5 > function_type | enumeral_type | retn | 4 > function_type | function_type | unql | 4 > function_type | type_decl | name | 4 > parm_decl | integer_type | argt | 4 > parm_decl | integer_type | type | 4 > tree_list | record_type | valu | 4 > type_decl | function_type | type | 4 > var_decl | record_type | type | 4 > void_type | type_decl | name | 4 > array_type | pointer_type | elts | 3 > function_type | complex_type | retn | 3 > parm_decl | parm_decl | chan | 3 > real_type | real_type | unql | 3 > type_decl | var_decl | chan | 3 > type_decl | void_type | type | 3 > void_type | void_type | unql | 3 > array_type | record_type | elts | 2 > field_decl | real_type | type | 2 > field_decl | union_type | type | 2 > integer_type | identifier_node | name | 2 > pointer_type | real_type | ptd | 2 > string_cst | array_type | type | 2 > union_type | field_decl | flds | 2 > union_type | integer_cst | size | 2 > var_decl | string_cst | init | 2 > var_decl | type_decl | chan | 2 > boolean_type | integer_cst | size | 1 > boolean_type | type_decl | name | 1 > type_decl | boolean_type | type | 1 > type_decl | union_type | type | 1 > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > _______________________________________________ > Introspector-developers mailing list > Int...@li... > https://lists.sourceforge.net/lists/listinfo/introspector-developers ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-18 22:50:17
|
Dear Sirs, Please excuse the follwing cross posting. I know that it is frowned apon, but I hope that you find the following mail interesting. Originally it was meant for the dotGNU mailing list, but I think that it is of relevance to this list. Please come and join the int...@so... mailing list for a open discussion about creating an GPLD/Free-Software reverse engineering and program understanding toolchain. Mike --- James Michael DuPont <mdu...@ya...> wrote: > Date: Thu, 18 Apr 2002 15:24:34 -0700 (PDT) > From: James Michael DuPont <mdu...@ya...> > Subject: Example SQL and XML of > DOTGNU/CSCC/csnodes.c > To: dev...@do... > CC: int...@so..., > gvo...@vo... > > Dear Fellow DotGNUers, > > I have done the first step in actually *Doing* > something for DotGNU and towards a bridge between > the > gcc and pnet and not just thinking and talking > about > what I want to do all the time. > > Taking the csnodes.c and running it through the > introspector for one. Tweaking and *SIMPLIFING* the > database model so that you can probably run in on > *ANY* sql database server. Putting it all on a > server > that you can download and play with. > Sorry that the last release from me did not have any > documentation or tips on how to use it. One has to > be > carefull, the asts are very BIG and hard to use. But > we will get there :=) > > I have reduced the database mode down to 3 tables > > *node_base > contains the ID and the type of the node > > *node_attr > contains the ID of the node, type and value of > the > attribute. > > *node_usage > contains the fromid, toid , types of nodes and > type > of relationship > > With these three tables you have a full graph of the > parse tree of the c# compilers node structure. > > The SQL for the tables is located on > http://introspector.sourceforge.net/dotgnu/simple.sql > > The data for inserting into the database you will > find > in a gz sql file here : > http://introspector.sourceforge.net/dotgnu/____global.xml.sql.gz > > The XML that was dumped you will find here : > http://introspector.sourceforge.net/dotgnu/____global.xml.gz > (If you are interested in parsing the XML yourself ) > The XML has the following structure: > > <xmlroot> # the root of the document > > # tells you what file that was compiled to get these > nodes > <xml_cfile name= NAME OF SOURCE FILE/> > > # each tree node in the parse tree produces such > a > xml entry > <node idx=NUMBER OF NODE > node_name=TYPE OF NODE > > > # RELATIONSHIPS - each relation to a different > node is contained inside of the NODE element > < # EACH RELATION is an entity of one of > the following types > name | type | unql | size | min | max | args > | > prms | scpe | flds | body | chan | valu | > op_0 | op_2 | val | purp | next > > > idx="THE ID OF THE OTHER NODE" > ref_node_name="THE TYPE OF OTHER NODE TYPE" > /> > > # ATTRIBUTES SOME of the following attributes > might be set : > <strg>THE VALUE OF A STRING</strg> > <srcl>SOURCE LINE</srcl> > <srcp>SOURCE FILE</srcp> > <prec>PRECISION</prec> > <algn>ALIGNMENT</algn> > <built_in>ALIGNMENT</built_in> > <low>LOW BYTE of a Constant</low> > <high>LOW BYTE of a Constant</high> > <lngth>Length of a string</lngth> > <qualconst>is const</qualconst> > <qualrest>?forgot for now :(</qualrest> > <qualvol>is volitile</qualcol> > <str>SOME TYPE OF PARAMETER FOR THE NODE (extern > for functions, struct for records)</str> > > </node> > # MANY OTHER NODEs may follow > </xmlroot> > > I am also testing a simple query language for > accessing the nodes. more about that next time. > > The files are located here : > http://introspector.sourceforge.net/dotgnu/ > > I hope that you can use these files and find them > helpfull. Next step is to create a cross reference > table between the GCC and the CSCC cores. > > Following are two example queries that show you the > power of the database. > > Mike > > First is a list of all the identifiers of > record_types > who name begin with IL > introspector_simple=# > > select distinct > value > from > node_usage u, > node_attr a , > node_base b > where > a.attr_type = 'strg' and > a.value like '"IL%' > and a.id=b.id > and u.to_id = b.id > and u.usage = 'name' > and u.from_type = 'record_type'; > > value > ---------------------------------------- > "ILNode_AddressOf__" > "ILNode_AddressOf_vtable__" > "ILNode_ArrayAccess__" > "ILNode_ArrayAccess_vtable__" > "ILNode_ArrayInit__" > "ILNode_ArrayInit_vtable__" > "ILNode_AsIs__" > "ILNode_AsIs_vtable__" > "ILNode_Assign__" > "ILNode_Assign_vtable__" > "ILNode_AttrArgs__" > "ILNode_BaseAccess__" > "ILNode_BaseAccess_vtable__" > "ILNode_BaseElement__" > "ILNode_BaseElement_vtable__" > "ILNode_BinaryArith__" > "ILNode_BinaryArith_vtable__" > "ILNode_BinaryBitwise__" > "ILNode_BinaryBitwise_vtable__" > "ILNode_BinaryExpression_vtable__" > "ILNode_BinaryShift__" > "ILNode_BinaryShift_vtable__" > "ILNode_CastSimple__" > "ILNode_CastSimple_vtable__" > "ILNode_CastType__" > "ILNode_CastType_vtable__" > "ILNode_Concat__" > "ILNode_Concat_vtable__" > "ILNode_Constant__" > "ILNode_Constant_vtable__" > "ILNode_DecimalType__" > "ILNode_DerefField__" > "ILNode_DerefField_vtable__" > "ILNode_Deref__" > "ILNode_Deref_vtable__" > "ILNode_DocComment__" > "ILNode_DocComment_vtable__" > "ILNode_DummyBinaryExpr__" > "ILNode_DummyBinaryExpr_vtable__" > "ILNode_DummySem_vtable__" > "ILNode_DummyUnaryExpr__" > "ILNode_DummyUnaryExpr_vtable__" > "ILNode_Dummy_vtable__" > "ILNode_Expression_vtable__" > "ILNode_FixAddress__" > "ILNode_FixAddress_vtable__" > "ILNode_FixExpr__" > "ILNode_FixExpr_vtable__" > "ILNode_FixedDeclList_vtable__" > "ILNode_Identifier__" > "ILNode_Identifier_vtable__" > "ILNode_IndexerAccess__" > "ILNode_IndexerAccess_vtable__" > "ILNode_IsNonNull__" > "ILNode_IsNonNull_vtable__" > "ILNode_IsNull__" > "ILNode_IsNull_vtable__" > "ILNode_LValueBinaryExpr_vtable__" > "ILNode_LValueNoRefUnaryExpr__" > "ILNode_LValueNoRefUnaryExpr_vtable__" > "ILNode_LValueNoRef_vtable__" > "ILNode_LValueUnaryExpr_vtable__" > "ILNode_LValue__" > "ILNode_LValue_vtable__" > "ILNode_List_vtable__" > "ILNode_LocalVariableType__" > "ILNode_LocalVariableType_vtable__" > "ILNode_LogicalAnd__" > "ILNode_LogicalAnd_vtable__" > "ILNode_LogicalNot__" > "ILNode_LogicalNot_vtable__" > "ILNode_LogicalOr__" > "ILNode_LogicalOr_vtable__" > "ILNode_MemberAccess__" > "ILNode_MemberAccess_vtable__" > "ILNode_MemberField__" > "ILNode_MemberField_vtable__" > "ILNode_MemberProperty__" > "ILNode_MemberProperty_vtable__" > "ILNode_NamedArg__" > "ILNode_NamedArg_vtable__" > "ILNode_Namespace__" > "ILNode_Namespace_vtable__" > "ILNode_Neg__" > "ILNode_Neg_vtable__" > "ILNode_NoOverflow__" > "ILNode_NoOverflow_vtable__" > "ILNode_NoPedantic__" > "ILNode_NoPedantic_vtable__" > "ILNode_Overflow__" > "ILNode_Overflow_vtable__" > "ILNode_Pedantic__" > "ILNode_Pedantic_vtable__" > "ILNode_PostDec__" > "ILNode_PostDec_vtable__" > "ILNode_PostInc__" > "ILNode_PostInc_vtable__" > "ILNode_PreDec__" > "ILNode_PreDec_vtable__" > "ILNode_PreInc__" > "ILNode_PreInc_vtable__" > "ILNode_QualIdent__" > "ILNode_QualIdent_vtable__" > "ILNode_Relational__" > "ILNode_Relational_vtable__" > "ILNode_Statement__" > "ILNode_Statement_vtable__" > "ILNode_StaticField__" > "ILNode_StaticProperty__" > "ILNode_StaticProperty_vtable__" > "ILNode_ToBool__" > "ILNode_ToBool_vtable__" > "ILNode_ToConst__" > "ILNode_ToConst_vtable__" > "ILNode_TypeSuffix__" > "ILNode_TypeSuffix_vtable__" > "ILNode_UnaryExpression_vtable__" > "ILNode_Unsafe__" > "ILNode_Unsafe_vtable__" > "ILNode_UserBinaryOp__" > "ILNode_UserBinaryOp_vtable__" > "ILNode_UserConversion__" > "ILNode_UserConversion_vtable__" > "ILNode_UserIncOrDec__" > "ILNode_UserIncOrDec_vtable__" > "ILNode_UserLogical__" > "ILNode_UserLogical_vtable__" > "ILNode_UserPostDec__" > "ILNode_UserPostDec_vtable__" > "ILNode_UserPostInc__" > "ILNode_UserPostInc_vtable__" > "ILNode_UserPreDec__" > "ILNode_UserPreDec_vtable__" > "ILNode_UserPreInc__" > "ILNode_UserPreInc_vtable__" > "ILNode_UserUnaryOp__" > "ILNode_UsingAlias__" > "ILNode_UsingAlias_vtable__" > "ILNode_UsingNamespace__" > "ILNode_UsingNamespace_vtable__" > "ILNode__" > "ILNode_vtable__" > > > Following is an example query that shows you what > type > of nodes point to what other types of nodes in the > current data set (It is loading right now, so not > finished yet). As you can see there is a lot of > information about the tree nodes as records and > fields. 1020 fields in the database, not bad! > > introspector_simple# select > from_type,to_type,usage,count(*) from node_usage > group > by from_type,to_type,usage order by count(*) desc; > from_type | to_type | usage | count > ---------------+-----------------+-------+------- > field_decl | identifier_node | name | 1020 > field_decl | integer_cst | size | 1020 > field_decl | record_type | scpe | 1007 > field_decl | field_decl | chan | 917 > field_decl | pointer_type | type | 754 > tree_list | tree_list | chan | 737 > function_decl | function_type | type | 512 > function_decl | identifier_node | name | 512 > tree_list | pointer_type | valu | 495 > function_decl | function_decl | chan | 485 > type_decl | type_decl | chan | 345 > function_type | integer_cst | size | 322 > function_type | tree_list | prms | 319 > record_type | field_decl | flds | 265 > record_type | integer_cst | size | 265 > tree_list | void_type | valu | 260 > type_decl | identifier_node | name | 258 > field_decl | integer_type | type | 229 > type_decl | record_type | type | 207 > integer_cst | integer_type | type | 193 > record_type | identifier_node | name | 182 > pointer_type | integer_cst | size | 165 > record_type | record_type | unql | 152 > tree_list | integer_type | valu | 152 > integer_type | integer_cst | max | 140 > integer_type | integer_cst | min | 140 > integer_type | integer_cst | size | 140 > function_type | integer_type | retn | 133 > type_decl | integer_type | type | 129 > integer_type | type_decl | name | 121 > integer_type | integer_type | unql | 106 > pointer_type | record_type | ptd | 105 > record_type | type_decl | name | 103 > function_type | pointer_type | retn | 91 > var_decl | identifier_node | name | 78 > function_type | void_type | retn | 71 > var_decl | integer_cst | size | 71 > var_decl | var_decl | chan | 69 > const_decl | enumeral_type | type | 65 > const_decl | identifier_node | name | 65 > tree_list | identifier_node | purp | 64 > tree_list | integer_cst | valu | 64 > const_decl | const_decl | chan | 60 > var_decl | integer_type | type | 44 > pointer_type | integer_type | ptd | 26 > type_decl | function_decl | chan | 24 > var_decl | pointer_type | type | 24 > function_decl | type_decl | chan | 19 > tree_list | enumeral_type | valu | 19 > pointer_type | pointer_type | unql | 18 > pointer_type | function_type | ptd | 17 > field_decl | union_type | scpe | 13 > tree_list | real_type | valu | 13 > field_decl | enumeral_type | type | 12 > function_type | real_type | retn | 12 > enumeral_type | integer_cst | max | 11 > enumeral_type | integer_cst | min | 11 > enumeral_type | integer_cst | size | 11 > enumeral_type | tree_list | csts | 11 > field_decl | record_type | type | 11 > parm_decl | function_decl | scpe | 11 > parm_decl | identifier_node | name | 11 > parm_decl | integer_cst | size | 11 > type_decl | enumeral_type | type | 11 > array_type | integer_cst | size | 9 > array_type | integer_type | domn | 9 > field_decl | array_type | type | 9 > pointer_type | type_decl | name | 9 > type_decl | pointer_type | type | 9 > array_type | integer_type | elts | 8 > complex_type | integer_cst | size | 8 > complex_type | type_decl | name | 8 > function_decl | parm_decl | args | 8 > function_decl | var_decl | chan | 8 > function_type | record_type | retn | 8 > pointer_type | void_type | ptd | 8 > type_decl | complex_type | type | 8 > parm_decl | pointer_type | argt | 7 > parm_decl | pointer_type | type | 7 > pointer_type | pointer_type | ptd | 7 > type_decl | real_type | type | 7 > var_decl | function_decl | chan | 7 > enumeral_type | enumeral_type | unql | 6 > enumeral_type | type_decl | name | 6 > real_type | integer_cst | size | 6 > real_type | type_decl | name | 6 > tree_list | complex_type | valu | 6 > type_decl | const_decl | chan | 6 > var_decl | array_type | type | 6 > const_decl | type_decl | chan | 5 > function_type | enumeral_type | retn | 4 > function_type | function_type | unql | 4 > function_type | type_decl | name | 4 > parm_decl | integer_type | argt | 4 > parm_decl | integer_type | type | 4 > tree_list | record_type | valu | 4 > type_decl | function_type | type | 4 > var_decl | record_type | type | 4 > void_type | type_decl | name | 4 > array_type | pointer_type | elts | 3 > function_type | complex_type | retn | 3 > parm_decl | parm_decl | chan | 3 > real_type | real_type | unql | 3 > type_decl | var_decl | chan | 3 > type_decl | void_type | type | 3 > void_type | void_type | unql | 3 > array_type | record_type | elts | 2 > field_decl | real_type | type | 2 > field_decl | union_type | type | 2 > integer_type | identifier_node | name | 2 > pointer_type | real_type | ptd | 2 > string_cst | array_type | type | 2 > union_type | field_decl | flds | 2 > union_type | integer_cst | size | 2 > var_decl | string_cst | init | 2 > var_decl | type_decl | chan | 2 > boolean_type | integer_cst | size | 1 > boolean_type | type_decl | name | 1 > type_decl | boolean_type | type | 1 > type_decl | union_type | type | 1 ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-18 22:24:39
|
Dear Fellow DotGNUers, I have done the first step in actually *Doing* something for DotGNU and towards a bridge between the gcc and pnet and not just thinking and talking about what I want to do all the time. Taking the csnodes.c and running it through the introspector for one. Tweaking and *SIMPLIFING* the database model so that you can probably run in on *ANY* sql database server. Putting it all on a server that you can download and play with. Sorry that the last release from me did not have any documentation or tips on how to use it. One has to be carefull, the asts are very BIG and hard to use. But we will get there :=) I have reduced the database mode down to 3 tables *node_base contains the ID and the type of the node *node_attr contains the ID of the node, type and value of the attribute. *node_usage contains the fromid, toid , types of nodes and type of relationship With these three tables you have a full graph of the parse tree of the c# compilers node structure. The SQL for the tables is located on http://introspector.sourceforge.net/dotgnu/simple.sql The data for inserting into the database you will find in a gz sql file here : http://introspector.sourceforge.net/dotgnu/____global.xml.sql.gz The XML that was dumped you will find here : http://introspector.sourceforge.net/dotgnu/____global.xml.gz (If you are interested in parsing the XML yourself ) The XML has the following structure: <xmlroot> # the root of the document # tells you what file that was compiled to get these nodes <xml_cfile name= NAME OF SOURCE FILE/> # each tree node in the parse tree produces such a xml entry <node idx=NUMBER OF NODE node_name=TYPE OF NODE > # RELATIONSHIPS - each relation to a different node is contained inside of the NODE element < # EACH RELATION is an entity of one of the following types name | type | unql | size | min | max | args | prms | scpe | flds | body | chan | valu | op_0 | op_2 | val | purp | next idx="THE ID OF THE OTHER NODE" ref_node_name="THE TYPE OF OTHER NODE TYPE" /> # ATTRIBUTES SOME of the following attributes might be set : <strg>THE VALUE OF A STRING</strg> <srcl>SOURCE LINE</srcl> <srcp>SOURCE FILE</srcp> <prec>PRECISION</prec> <algn>ALIGNMENT</algn> <built_in>ALIGNMENT</built_in> <low>LOW BYTE of a Constant</low> <high>LOW BYTE of a Constant</high> <lngth>Length of a string</lngth> <qualconst>is const</qualconst> <qualrest>?forgot for now :(</qualrest> <qualvol>is volitile</qualcol> <str>SOME TYPE OF PARAMETER FOR THE NODE (extern for functions, struct for records)</str> </node> # MANY OTHER NODEs may follow </xmlroot> I am also testing a simple query language for accessing the nodes. more about that next time. The files are located here : http://introspector.sourceforge.net/dotgnu/ I hope that you can use these files and find them helpfull. Next step is to create a cross reference table between the GCC and the CSCC cores. Following are two example queries that show you the power of the database. Mike First is a list of all the identifiers of record_types who name begin with IL introspector_simple=# select distinct value from node_usage u, node_attr a , node_base b where a.attr_type = 'strg' and a.value like '"IL%' and a.id=b.id and u.to_id = b.id and u.usage = 'name' and u.from_type = 'record_type'; value ---------------------------------------- "ILNode_AddressOf__" "ILNode_AddressOf_vtable__" "ILNode_ArrayAccess__" "ILNode_ArrayAccess_vtable__" "ILNode_ArrayInit__" "ILNode_ArrayInit_vtable__" "ILNode_AsIs__" "ILNode_AsIs_vtable__" "ILNode_Assign__" "ILNode_Assign_vtable__" "ILNode_AttrArgs__" "ILNode_BaseAccess__" "ILNode_BaseAccess_vtable__" "ILNode_BaseElement__" "ILNode_BaseElement_vtable__" "ILNode_BinaryArith__" "ILNode_BinaryArith_vtable__" "ILNode_BinaryBitwise__" "ILNode_BinaryBitwise_vtable__" "ILNode_BinaryExpression_vtable__" "ILNode_BinaryShift__" "ILNode_BinaryShift_vtable__" "ILNode_CastSimple__" "ILNode_CastSimple_vtable__" "ILNode_CastType__" "ILNode_CastType_vtable__" "ILNode_Concat__" "ILNode_Concat_vtable__" "ILNode_Constant__" "ILNode_Constant_vtable__" "ILNode_DecimalType__" "ILNode_DerefField__" "ILNode_DerefField_vtable__" "ILNode_Deref__" "ILNode_Deref_vtable__" "ILNode_DocComment__" "ILNode_DocComment_vtable__" "ILNode_DummyBinaryExpr__" "ILNode_DummyBinaryExpr_vtable__" "ILNode_DummySem_vtable__" "ILNode_DummyUnaryExpr__" "ILNode_DummyUnaryExpr_vtable__" "ILNode_Dummy_vtable__" "ILNode_Expression_vtable__" "ILNode_FixAddress__" "ILNode_FixAddress_vtable__" "ILNode_FixExpr__" "ILNode_FixExpr_vtable__" "ILNode_FixedDeclList_vtable__" "ILNode_Identifier__" "ILNode_Identifier_vtable__" "ILNode_IndexerAccess__" "ILNode_IndexerAccess_vtable__" "ILNode_IsNonNull__" "ILNode_IsNonNull_vtable__" "ILNode_IsNull__" "ILNode_IsNull_vtable__" "ILNode_LValueBinaryExpr_vtable__" "ILNode_LValueNoRefUnaryExpr__" "ILNode_LValueNoRefUnaryExpr_vtable__" "ILNode_LValueNoRef_vtable__" "ILNode_LValueUnaryExpr_vtable__" "ILNode_LValue__" "ILNode_LValue_vtable__" "ILNode_List_vtable__" "ILNode_LocalVariableType__" "ILNode_LocalVariableType_vtable__" "ILNode_LogicalAnd__" "ILNode_LogicalAnd_vtable__" "ILNode_LogicalNot__" "ILNode_LogicalNot_vtable__" "ILNode_LogicalOr__" "ILNode_LogicalOr_vtable__" "ILNode_MemberAccess__" "ILNode_MemberAccess_vtable__" "ILNode_MemberField__" "ILNode_MemberField_vtable__" "ILNode_MemberProperty__" "ILNode_MemberProperty_vtable__" "ILNode_NamedArg__" "ILNode_NamedArg_vtable__" "ILNode_Namespace__" "ILNode_Namespace_vtable__" "ILNode_Neg__" "ILNode_Neg_vtable__" "ILNode_NoOverflow__" "ILNode_NoOverflow_vtable__" "ILNode_NoPedantic__" "ILNode_NoPedantic_vtable__" "ILNode_Overflow__" "ILNode_Overflow_vtable__" "ILNode_Pedantic__" "ILNode_Pedantic_vtable__" "ILNode_PostDec__" "ILNode_PostDec_vtable__" "ILNode_PostInc__" "ILNode_PostInc_vtable__" "ILNode_PreDec__" "ILNode_PreDec_vtable__" "ILNode_PreInc__" "ILNode_PreInc_vtable__" "ILNode_QualIdent__" "ILNode_QualIdent_vtable__" "ILNode_Relational__" "ILNode_Relational_vtable__" "ILNode_Statement__" "ILNode_Statement_vtable__" "ILNode_StaticField__" "ILNode_StaticProperty__" "ILNode_StaticProperty_vtable__" "ILNode_ToBool__" "ILNode_ToBool_vtable__" "ILNode_ToConst__" "ILNode_ToConst_vtable__" "ILNode_TypeSuffix__" "ILNode_TypeSuffix_vtable__" "ILNode_UnaryExpression_vtable__" "ILNode_Unsafe__" "ILNode_Unsafe_vtable__" "ILNode_UserBinaryOp__" "ILNode_UserBinaryOp_vtable__" "ILNode_UserConversion__" "ILNode_UserConversion_vtable__" "ILNode_UserIncOrDec__" "ILNode_UserIncOrDec_vtable__" "ILNode_UserLogical__" "ILNode_UserLogical_vtable__" "ILNode_UserPostDec__" "ILNode_UserPostDec_vtable__" "ILNode_UserPostInc__" "ILNode_UserPostInc_vtable__" "ILNode_UserPreDec__" "ILNode_UserPreDec_vtable__" "ILNode_UserPreInc__" "ILNode_UserPreInc_vtable__" "ILNode_UserUnaryOp__" "ILNode_UsingAlias__" "ILNode_UsingAlias_vtable__" "ILNode_UsingNamespace__" "ILNode_UsingNamespace_vtable__" "ILNode__" "ILNode_vtable__" Following is an example query that shows you what type of nodes point to what other types of nodes in the current data set (It is loading right now, so not finished yet). As you can see there is a lot of information about the tree nodes as records and fields. 1020 fields in the database, not bad! introspector_simple# select from_type,to_type,usage,count(*) from node_usage group by from_type,to_type,usage order by count(*) desc; from_type | to_type | usage | count ---------------+-----------------+-------+------- field_decl | identifier_node | name | 1020 field_decl | integer_cst | size | 1020 field_decl | record_type | scpe | 1007 field_decl | field_decl | chan | 917 field_decl | pointer_type | type | 754 tree_list | tree_list | chan | 737 function_decl | function_type | type | 512 function_decl | identifier_node | name | 512 tree_list | pointer_type | valu | 495 function_decl | function_decl | chan | 485 type_decl | type_decl | chan | 345 function_type | integer_cst | size | 322 function_type | tree_list | prms | 319 record_type | field_decl | flds | 265 record_type | integer_cst | size | 265 tree_list | void_type | valu | 260 type_decl | identifier_node | name | 258 field_decl | integer_type | type | 229 type_decl | record_type | type | 207 integer_cst | integer_type | type | 193 record_type | identifier_node | name | 182 pointer_type | integer_cst | size | 165 record_type | record_type | unql | 152 tree_list | integer_type | valu | 152 integer_type | integer_cst | max | 140 integer_type | integer_cst | min | 140 integer_type | integer_cst | size | 140 function_type | integer_type | retn | 133 type_decl | integer_type | type | 129 integer_type | type_decl | name | 121 integer_type | integer_type | unql | 106 pointer_type | record_type | ptd | 105 record_type | type_decl | name | 103 function_type | pointer_type | retn | 91 var_decl | identifier_node | name | 78 function_type | void_type | retn | 71 var_decl | integer_cst | size | 71 var_decl | var_decl | chan | 69 const_decl | enumeral_type | type | 65 const_decl | identifier_node | name | 65 tree_list | identifier_node | purp | 64 tree_list | integer_cst | valu | 64 const_decl | const_decl | chan | 60 var_decl | integer_type | type | 44 pointer_type | integer_type | ptd | 26 type_decl | function_decl | chan | 24 var_decl | pointer_type | type | 24 function_decl | type_decl | chan | 19 tree_list | enumeral_type | valu | 19 pointer_type | pointer_type | unql | 18 pointer_type | function_type | ptd | 17 field_decl | union_type | scpe | 13 tree_list | real_type | valu | 13 field_decl | enumeral_type | type | 12 function_type | real_type | retn | 12 enumeral_type | integer_cst | max | 11 enumeral_type | integer_cst | min | 11 enumeral_type | integer_cst | size | 11 enumeral_type | tree_list | csts | 11 field_decl | record_type | type | 11 parm_decl | function_decl | scpe | 11 parm_decl | identifier_node | name | 11 parm_decl | integer_cst | size | 11 type_decl | enumeral_type | type | 11 array_type | integer_cst | size | 9 array_type | integer_type | domn | 9 field_decl | array_type | type | 9 pointer_type | type_decl | name | 9 type_decl | pointer_type | type | 9 array_type | integer_type | elts | 8 complex_type | integer_cst | size | 8 complex_type | type_decl | name | 8 function_decl | parm_decl | args | 8 function_decl | var_decl | chan | 8 function_type | record_type | retn | 8 pointer_type | void_type | ptd | 8 type_decl | complex_type | type | 8 parm_decl | pointer_type | argt | 7 parm_decl | pointer_type | type | 7 pointer_type | pointer_type | ptd | 7 type_decl | real_type | type | 7 var_decl | function_decl | chan | 7 enumeral_type | enumeral_type | unql | 6 enumeral_type | type_decl | name | 6 real_type | integer_cst | size | 6 real_type | type_decl | name | 6 tree_list | complex_type | valu | 6 type_decl | const_decl | chan | 6 var_decl | array_type | type | 6 const_decl | type_decl | chan | 5 function_type | enumeral_type | retn | 4 function_type | function_type | unql | 4 function_type | type_decl | name | 4 parm_decl | integer_type | argt | 4 parm_decl | integer_type | type | 4 tree_list | record_type | valu | 4 type_decl | function_type | type | 4 var_decl | record_type | type | 4 void_type | type_decl | name | 4 array_type | pointer_type | elts | 3 function_type | complex_type | retn | 3 parm_decl | parm_decl | chan | 3 real_type | real_type | unql | 3 type_decl | var_decl | chan | 3 type_decl | void_type | type | 3 void_type | void_type | unql | 3 array_type | record_type | elts | 2 field_decl | real_type | type | 2 field_decl | union_type | type | 2 integer_type | identifier_node | name | 2 pointer_type | real_type | ptd | 2 string_cst | array_type | type | 2 union_type | field_decl | flds | 2 union_type | integer_cst | size | 2 var_decl | string_cst | init | 2 var_decl | type_decl | chan | 2 boolean_type | integer_cst | size | 1 boolean_type | type_decl | name | 1 type_decl | boolean_type | type | 1 type_decl | union_type | type | 1 __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-06 17:22:47
|
Upload of tests : I have uploaded a set of tests to the web page, they contain one xml file per function for a large set of functions for gcc. http://introspector.sourceforge.net/xml/ contains gzipped xml. The file http://introspector.sourceforge.net/sql/ contains the sql files. ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: James M. D. <mdu...@ya...> - 2002-04-06 13:54:27
|
The first binary release of what could be considered a usable version 0.4 of the introspector is available. I have taken cleaned up the project sourceforge page. CVS is now in use, please check the cvs for source code. The patched version of gcc is located in the following release : "patched gcc/working without database" release. Here is a link to the raw download of the patched gcc compiler for linux : http://prdownloads.sourceforge.net/introspector/introspector_simple.tgz The MD5 is d439e3372c1f788c40f49ed4bb473caf. This release contains only the cc1 compiler, and does not contain the preprocessor. ===== James Michael DuPont __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
|
From: Dupont, M. <mic...@mc...> - 2002-02-25 08:40:52
|
I have figured out how to delete files from CVS and have cleaned up the CVS tree. mike |
1 message has been excluded from this view by a project administrator.
