Re: gcc thoughts
On Sat, 2008-01-26 at 09:24 +0200, Amit Aronovitch wrote: Leonid Podolny wrote: [... snipped ...] This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. [... snipped ...] Sorry I did not read all the replys very thoroughly, but I did notice that nobody mentioned gcc_xml http://www.gccxml.org/ It does much more than what you need, but I'm sure that the information you seek is in fact stored in the output (I believe a simple SAX processor should be able to extract it fast enough to be integrated into the dev environ). Besides - you could probably use more than just the location of the defs. From a brief glance at the gccxml Web site, the project looks to be relatively unmaintained (at least). The most recent release was at 2004. --- Omer -- My Commodore 64 is suffering from slowness and insufficiency of memory; and its display device is grievously short of pixels. Can anyone help? My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html = 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]
Re: gcc thoughts
On Jan 26, 2008 10:16 AM, Omer Zak [EMAIL PROTECTED] wrote: From a brief glance at the gccxml Web site, the project looks to be relatively unmaintained (at least). The most recent release was at 2004. --- Omer Well, I have not used it myself, but Py++/pygccxml, ( http://www.language-binding.net/ ) which does use it (last I heard at least), have updates to the SF svn repo dated 30 minutes ago. So I guess Roman Yakovenko should be able to give you a more uptodate feedback if you seriously consider using it. AA = 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]
Re: gcc thoughts
Leonid Podolny wrote: Hi, list, This letter is probably better suited to hackers-il, but I need help from people that are better acquainted with a development process of gcc. This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. It would be simply fantastic. The index would reflect the actual set of #ifdef's I currently work with. It would always point you to the header file that was actually #include-d. It would be immediately useful to almost everyone in FOSS world. I have a couple of ideas, how it might be tailored into gcc running sequence. However, I'm a humble gcc user and I have almost no experience with its inner workings. The idea by itself is so obvious and on-the-surface that it everyone using gcc must come up with it sooner or later. There must be a very sound technical reason not to do so. What is it? Sorry I did not read all the replys very thoroughly, but I did notice that nobody mentioned gcc_xml http://www.gccxml.org/ It does much more than what you need, but I'm sure that the information you seek is in fact stored in the output (I believe a simple SAX processor should be able to extract it fast enough to be integrated into the dev environ). Besides - you could probably use more than just the location of the defs. Another possibility is to use the XML output of doxygen. (both tools are successfuly used by automatic tools for auto-generating python interface for C++ libraries). AA = 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]
gcc thoughts
Hi, list, This letter is probably better suited to hackers-il, but I need help from people that are better acquainted with a development process of gcc. This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. It would be simply fantastic. The index would reflect the actual set of #ifdef's I currently work with. It would always point you to the header file that was actually #include-d. It would be immediately useful to almost everyone in FOSS world. I have a couple of ideas, how it might be tailored into gcc running sequence. However, I'm a humble gcc user and I have almost no experience with its inner workings. The idea by itself is so obvious and on-the-surface that it everyone using gcc must come up with it sooner or later. There must be a very sound technical reason not to do so. What is it? -- 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]
Re: gcc thoughts
On Tue, Jan 15, 2008 at 12:57:36PM +0200, Leonid Podolny wrote: Hi, list, This letter is probably better suited to hackers-il, but I need help from people that are better acquainted with a development process of gcc. This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. It would be simply fantastic. The index would reflect the actual set of #ifdef's I currently work with. It would always point you to the header file that was actually #include-d. It would be immediately useful to almost everyone in FOSS world. I have a couple of ideas, how it might be tailored into gcc running sequence. However, I'm a humble gcc user and I have almost no experience with its inner workings. The idea by itself is so obvious and on-the-surface that it everyone using gcc must come up with it sooner or later. There must be a very sound technical reason not to do so. What is it? I recently read an interesting interview with a gcc developer who works on this and more: http://lwn.net/Articles/249416/ -- Didi = 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]
Re: gcc thoughts
1. compilation could be broken and you still need to browse it 2. gcc don't know about cpp (preprocessor) defines more tricks: gcc -E gives you preprocessed file and you could check defines and ifdefs objdump -S - gives you disassemble On Jan 15, 2008 12:57 PM, Leonid Podolny [EMAIL PROTECTED] wrote: Hi, list, This letter is probably better suited to hackers-il, but I need help from people that are better acquainted with a development process of gcc. This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. It would be simply fantastic. The index would reflect the actual set of #ifdef's I currently work with. It would always point you to the header file that was actually #include-d. It would be immediately useful to almost everyone in FOSS world. I have a couple of ideas, how it might be tailored into gcc running sequence. However, I'm a humble gcc user and I have almost no experience with its inner workings. The idea by itself is so obvious and on-the-surface that it everyone using gcc must come up with it sooner or later. There must be a very sound technical reason not to do so. What is it? -- 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] -- Constantine Shulyupin Freelance Embedded Linux Engineer 054-4234440 http://www.linuxdriver.co.il/ = 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]
Re: gcc thoughts
On Tue, Jan 15, 2008 at 01:47:22PM +0200, Constantine Shulyupin wrote: 1. compilation could be broken and you still need to browse it 2. gcc don't know about cpp (preprocessor) defines more tricks: gcc -E gives you preprocessed file and you could check defines and ifdefs objdump -S - gives you disassemble You meant: gcc -S, to save the middleware. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend = 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]
Re: gcc thoughts
Constantine Shulyupin wrote: 1. compilation could be broken and you still need to browse it Yes, but you can always revert to cscope to solve compilation errors. 2. gcc don't know about cpp (preprocessor) defines First, cpp could pass this info via intermediate files. Second, this info info somehow does reach a compiler, because a debuginfo ELF section contains information about a file and a line number every instruction came from. more tricks: gcc -E gives you preprocessed file and you could check defines and ifdefs objdump -S - gives you disassemble Yes, I know. Why? -- 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]
Re: gcc thoughts
-S too On Jan 15, 2008 2:45 PM, Tzafrir Cohen [EMAIL PROTECTED] wrote: On Tue, Jan 15, 2008 at 01:47:22PM +0200, Constantine Shulyupin wrote: 1. compilation could be broken and you still need to browse it 2. gcc don't know about cpp (preprocessor) defines more tricks: gcc -E gives you preprocessed file and you could check defines and ifdefs objdump -S - gives you disassemble You meant: gcc -S, to save the middleware. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend = 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] -- Constantine Shulyupin Freelance Embedded Linux Engineer 054-4234440 http://www.linuxdriver.co.il/ = 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]
Re: gcc thoughts
On Jan 15, 2008 2:28 PM, Leonid Podolny [EMAIL PROTECTED] wrote: Constantine Shulyupin wrote: 1. compilation could be broken and you still need to browse it Yes, but you can always revert to cscope to solve compilation errors. If you could revert, why do need duplicated functionality in gcc? 2. gcc don't know about cpp (preprocessor) defines First, cpp could pass this info via intermediate files. Second, this info info somehow does reach a compiler, because a debuginfo ELF section contains information about a file and a line number every instruction came from. Tell me please how info of #define goes to debuginfo? more tricks: gcc -E gives you preprocessed file and you could check defines and ifdefs objdump -S - gives you disassemble Yes, I know. Why? It it possible to generate ctags file from objdump -S output and other listings. -- Leonid Podolny | [EMAIL PROTECTED] | Software Engineer| +972- 3-7668960 Linux Platform Team | +972-54-5696948 -- Constantine Shulyupin Freelance Embedded Linux Engineer 054-4234440 http://www.linuxdriver.co.il/ = 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]
Re: gcc thoughts
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. -- Ori Idan Leonid Podolny wrote: Hi, list, This letter is probably better suited to hackers-il, but I need help from people that are better acquainted with a development process of gcc. This morning, while browsing through pages of frustratingly irrelevant cscope output, I got an idea. In every kosher *nix development environment, the cross-references (i.e. jump to definition of this struct/function) are built by some crippled 3rd party tool (such as ctags, cscope or home-brewed set of elisp scrips). On the other hand, the only tool that actually knows what is going on during compilation is gcc, so it's only logical that it should build cross-references along the way. It would be simply fantastic. The index would reflect the actual set of #ifdef's I currently work with. It would always point you to the header file that was actually #include-d. It would be immediately useful to almost everyone in FOSS world. I have a couple of ideas, how it might be tailored into gcc running sequence. However, I'm a humble gcc user and I have almost no experience with its inner workings. The idea by itself is so obvious and on-the-surface that it everyone using gcc must come up with it sooner or later. There must be a very sound technical reason not to do so. What is it? = 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]
Re: gcc thoughts
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]
Re: gcc thoughts
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]
Re: gcc thoughts
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. -- Ori Idan = 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]
Re: gcc thoughts
BTW, I have script, that makes tags for Linux kernel only for configured architecture. On Jan 15, 2008 5:05 PM, Leonid Podolny [EMAIL PROTECTED] wrote: were never included (such as wrong architectures and not included code during kernel development). -- Constantine Shulyupin Freelance Embedded Linux Engineer 054-4234440 http://www.linuxdriver.co.il/ = 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]
Re: gcc thoughts
This script builds name file:line table from object/exe file. It is
easy to make tags from this.
objsrc()
{
nm --defined $1 | cut -f 1 -d ' ' | addr2line -e bin/eb_client
/tmp/lines
nm --defined $1 | cut -f 3 -d ' ' /tmp/name
paste /tmp/name /tmp/lines
}
On Jan 15, 2008 12:57 PM, Leonid Podolny [EMAIL PROTECTED] wrote:
Hi, list,
This letter is probably better suited to hackers-il, but I need help
from people that are better acquainted with a development process of gcc.
This morning, while browsing through pages of frustratingly irrelevant
cscope output, I got an idea. In every kosher *nix development
environment, the cross-references (i.e. jump to definition of this
struct/function) are built by some crippled 3rd party tool (such as
ctags, cscope or home-brewed set of elisp scrips). On the other hand,
the only tool that actually knows what is going on during compilation is
gcc, so it's only logical that it should build cross-references along
the way.
It would be simply fantastic. The index would reflect the actual set of
#ifdef's I currently work with. It would always point you to the header
file that was actually #include-d. It would be immediately useful to
almost everyone in FOSS world.
I have a couple of ideas, how it might be tailored into gcc running
sequence. However, I'm a humble gcc user and I have almost no
experience with its inner workings.
The idea by itself is so obvious and on-the-surface that it everyone
using gcc must come up with it sooner or later. There must be a very
sound technical reason not to do so. What is it?
--
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]
--
Constantine Shulyupin
Freelance Embedded Linux Engineer
054-4234440
http://www.linuxdriver.co.il/
=
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]
