I don't have a lot of experience with GCC development. I know enough to
have done what i needed to do.
As for a place to start i would read the GCC internals documentation as
a first step. There is also a lot of info on the Wiki too. However a lot
of documentation is specific to either creating a new front end or
porting GCC to a new platform. The mistake i made first off was to only
read the documentation sections i thought were relevant for me and
ignore the rest. This turned out to be an issue as i skipped some things
which have come back to bite me.
I would then download a version of GCC either from CVS or a past stable
version and get it to compile, install and run successfully. I found
learning stuff was difficult, I ended up doing a lot by trial and error
as i just could not find all the information i needed. The GCC internals
manual will be your friend, however even more useful were the comments
in the various header files like tree.h There were numerous macros in
there that i found useful that are not mentioned in the code.
As for where to hook into the code, for your project others will have to
help you here. I did not need to modify the parser in any way and i also
did not have to generate any tree nodes only analyze what existed. I
leave this open for others to comment on.
I agree with your comments that having the code for EDoc++ outside GCC
is a problem. My patch is for GCC 4.0.1 which had just been released
when i started writing it. I am not yet sure if it will be a big task to
port to the newer version of GCC.
I think your extension could be useful, but it would be MORE useful if
it was adopted by the wider community. You may find that if it is not
possible to make the code compile with other compilers that dont have
the extension you will be less likely to have people adopt it. So think
about how people could use macros to use the source unchanged without
too much verbosity and have it compile fine on older GCC versions. I.e.
maybe renaming _throws to standard throws with a macro if the compile
does not support the extension. Simple but something to think about.
If i had a preferred option I would get people to change the C++
standard to mandate that compilers had to check exceptions at compile
time just like java, and deal with the screaming masses whose code no
longer compiles later...
I am curious though that when you wrap other functions in try/catch
blocks what will you do if you do receive an exception that does not
match that specifier?
Sorry if my comments were discouraging. It didn't mean to be.
I hope this is a start. I guess you may have already read that
documentation, in which case i guess you need to start looking at how to
add stuff to the parser. Which i know absolutely nothing about.
Finally Mike mentioned using LTO. This is not necessary for your
modification idea, but with LTO what i have implemented in EDoc++ could
be integrated into GCC and run at link time in order to achieve a
slightly similar result. I might look into this at a later time.
Brendon.
Sergio Giro wrote:
> On Apr 2, 2007, at 2:32 AM, Brendon Costa wrote:
>> I have for a while been working on a tool that performs static
>> analysis
> I agree that Brendon's project is a very good idea, but I still
> have an argument against it: having such an analysis into gcc forces
> the gcc development community to maintain the code performing the
> analysis. Having this analysis outside gcc makes it less likely to
> remain in time. If I start a huge project, I would prefer to wrap
> external functions into try { } catch(...) blocks (in a huge project,
> the time spent by this task is negligeable) instead of relying on an
> external tool...
> I agree that edoc++ is very useful (particularly, generating
> documentation for Doxygen is a very nice issue!), but I keep
> interested to implement this feature inside gcc.
> I write here because I am looking forward for your discouraging
> comments! Maybe you can convince that this is not useful...
> If you consider this analysis to be useful, I will be grateful for
> any ideas concerning where and how to start looking in order to
> implement the analysis.
> Cheers,
> Sergio
>
> On 4/2/07, Mike Stump <[EMAIL PROTECTED]> wrote:
>
>> Ah, yeah, that I suspect would be a even better way to do this...
>> Itt would be nice if gcc/g++ had more support for static analysis
>> tools... Maybe with LTO.
>>
>
>
>
>
