Wishlist: gcc outputs ctags-type info

[Enrique Perez-Terron <enrique dot perez-terron at norway dot online dot no>]

I wish gcc had an option to output data similar to ctags as it parses
its input. 

It should not output anything for code skipped by the preprocessor.

On the other hand I also wish the preprocessor would output similar data
for symbols it defines as it scans its input. Again, code skipped should
not produce any output.

Reason:

1. Modern object-oriented programs (even if written in C, or especially
then) often invoke code through pointers that are structure members.
Structure members often have short names that equal names of formal
parameter to functions, local variables of functions, other structure
members in other structures, etc. 

No tool I know about is good at finding the places that a particular
structure member is used unless the structure member has a name that is
unique across all structures, local variables, and global ones. This
makes it particularly hard to follow the logic of a program.

If the program is working well and is well designed, you can come a long
way with a little guessing and grepping, but what if there is a
programming error, things can change in places very hard to find.

2. No ctags tool I know about exclude code that is to be skipped during
compilation. (Yes, of course I know that what is skipped during one
compilation might be include in the next.) When researching a difficult
problem it helps reduce noise and free the researcher's mind to
concentrate on what matters, if she can see only the symbols that are
relevant to the case that she is investigating.

A corollary to this, is that it would sometimes be handy to have the
preprocessor write a half-processed file: Read and process include
files, but do not produce output from them. Replace all #if*, #else,
#endif statements with empty lines, and also replace lines not
processed. Leave the preprocessor definitions in place for the human
reader to see. The purpose of this is to arrive at the maximally
readable version of code with lots of conditional compiling, showing
just what is actually compiled in the present run.

3. Writing a tools that does this well duplicates much of the effort put
into the actual parsers in gcc.

Suggestion:

I suggest two options, --output-tags and --tags-file="path/to/file".
--tags-file may have a default value. The file should be opened in
append mode.

The output should have the form of SQL statements to insert the data
into an SQL database. The statements should assume the following schema:

create table compilations(
  compilation number, -- Random 64-bit number, primary key
  host string,        -- Host compiler runs on
  when datetime,      -- When compilation started
  file string,
  preprocessor_options string, -- sort options alphabetically?
  compiler_options string, -- sort options in some canonical order?
  compiler_version string
);

create table declarations(
  declaration number,  -- sequential number, primary key together with
                       -- 'compilation'
  compilation number,  -- foregn key into compilations
  identifier string,   -- the declared identifier
  kind string,         -- one of 
			-- preprocessor, 
			-- global, 
			-- static, 
			-- local (also if formal parameter), 
			-- member.
  context string,      -- specify: 
			-- function (if local) or 
			-- class (if member) or.
			-- null otherwise.
			-- Find a suitable syntax to identify a class 
			-- that is local to a function, etc.
  file string,
  line number,
  definition boolean
);

create table uses (
  use number number,  -- sequential number, primary key together with 
		      -- 'declaration' and 'compilation'
  declaration number, -- foreign key into declarations
  compilation number, -- foreign key into compilations
  assignment boolean  -- true if value is being set. Also true if 
		      -- address being passed to a function, except if 
		      -- as pointer to const.
  file string,
  line number
);

It is of course not all that important what format the output has, as
long as it is not too hard to parse, and the required information is
there. 

Most likely I have forgotten a couple of important pieces of
information.  I hope you will amend the table definitions if you see
anything missing.

It comes to my mind that the information I am requesting is not very
different from the debug information. Perhaps the information I want can
be found by using -g and parsing the resulting .o file.

Is there any hope this can be done?  Anyone else liking the idea?
Any important problems I have overlooked?

I guess I cannot contribute without first taking a two-year sabbat to
study the gcc code. Or, perhaps somebody can give some pointers...

Regards, Enrique