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: Florian Weimer <fweimer at redhat dot com>
- To: gcc frickler <gccfrickler at privatdemail dot net>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Mon, 27 May 2013 10:10:52 +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>
On 05/26/2013 11:08 AM, gcc frickler wrote:
Good point, but i think that is dangerous.
I have >5k source-Files and need to have this fixed in a semi-automatic
way (ctags did not find all of them).
I need a compiler warning on non-static/non-const globals because
sometimes (< 2 %) they are meant to be as global as it gets. I am trying
to build up a cross compilation unit database from the warnings to see
where are unintended clashes and what was intended (imported elsewhere
via the extern keyword).
It's probably easier if you look at the generated DSOs, extract the
symbol list, and join the result with itself to detecting collisions.
Something like that:
<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).
--
Florian Weimer / Red Hat Product Security Team