Ori Idan wrote:
Leonid Podolny wrote:
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.
Map file is not created by gcc, it is created by ld that is called by
gcc after all files are compiled to object files.
So it has nothing to do with the assembler.
Woops, I wasn't aware of that, so I called "map file" to the files that
my indexer would produce.
sed "s/map/index/g" all the above
--
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]
