Ori Idan wrote:
gcc as a compiler always work on a single file.
For a cross reference, you need something that knows all the files, this
is done by ld and it does create a cross reference, this is the map file.
However, during development, I still can not link (some files and
functions are broken) therefore I need different tool for the cross
reference.
I thought that cc would drop aside a map file and pass a compiled file
to assembler. This way it doesn't really interfere with
one-file-at-a-time paradigm, because the map file is a by-product, it's
not really passed to the assembler afterwards. A map file would hold
only information about this specific .c file (preprocessed, i.e. along
with its headers). It would include the information about the file for
its external user, such as list of functions defined (name and file:line
for every one), non-static variables (name and file:line), etc.
How to turn these files into something more useful is a different issue.
At a first stage, it's possible to write an external utility that
would take specified map files, reverse the data (i.e. turn "a.c defines
func1(), func2()" into "func1() is defined in a.c" and "func2() is
defined in a.c") and build common index. Then you would tailor it into
makefiles to build project-wide index. The result will still be much
better than cscope output, because you will never see header files that
were never included (such as wrong architectures and not included code
during kernel development). It will also correctly see your current
settings of #ifdef's (again, in kernel, it means that it reflects your
current .config). Cscope also sometimes fails to parse .c file
correctly, such as failing to understand that some specific line is a
function declaration if you put line feed between a returned value type
and a name. This issue will also be gone -- the index is effectively
built by the same semantical analyzer that compiler uses.
A disadvantages of this approach are also clear. The data reversing part
is error-prone and actually means duplicating part of the functionality
of ld, so this part should somehow move to ld. Or maybe not -- for
example, duplicate symbols cause ld to fail, but should not be a problem
for indexer. It all requires careful design.
Tell me if all the above makes any sense.
--
Leonid Podolny | [EMAIL PROTECTED]
|
Software Engineer | +972- 3-7668960
Linux Platform Team | +972-54-5696948
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
