This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Plugin: global vs global static in c/c++ AST representation
- From: gcc frickler <gccfrickler at privatdemail dot net>
- To: gcc-help at gcc dot gnu dot org
- Date: Wed, 29 May 2013 15:34:33 +0200
- Subject: Re: Plugin: global vs global static in c/c++ AST representation
- References: <519E6FC6 dot 5030502 at privatdemail dot net> <519EF0F9 dot 8040804 at privatdemail dot net> <CAKOQZ8zHqx64kRZLw9pdgGvQMrnk-iVaHV_V7r80FNdDe7UmKA at mail dot gmail dot com> <51A09160 dot 8020109 at privatdemail dot net> <CAKOQZ8xD=_xPhag-iaFU7c6G9zdNFxLGQAWew7pTkqWJ0gZrpA at mail dot gmail dot com> <51A1D11C dot 70205 at privatdemail dot net> <51A3150C dot 4050409 at redhat dot com>
Am 27.05.2013 10:10, schrieb Florian Weimer:
> <https://github.com/fweimer/symboldb/blob/master/doc/examples/library-symbol-collisions.txt>
>
>
> I think you can cut down the number of false positives by taking ELF
> binding types into account (which I have not investigated yet).
>
I allready tried objdump and nm and size but there are some difficulty.
I found it very hard to separate "static within function", "global" and
"global static".
It does not easyly provide the location in the source file.
It does not allow me to insult the develloper at compile time.
Even if i could fix it by now it just takes just a few months and the
clash may happen again.
I think i'd go for the plugin solution and reinvestiagte the c-frontend.
In c++ i'm very positive about the decl_this_staic predicate.