Plugin: global vs global static in c/c++ AST representation

[gcc frickler]

Hi,


> On Sat, May 25, 2013 at 3:24 AM, gcc frickler
> <gccfrickler@privatdemail.net> wrote:
>> Hi,
>>>>
>>>> It does not seem to be a attribute of a VAR_DECL
>>>> The static predicate in the bitfield is just saying it goes in the bss
>>>> segment (true in all of the above cases) and has got nothing to do with
>>>> the static keyword which just controls visibility on link time.
>> I think i spotted it in the DECL_THIS_STATIC  / DECL_THIS_EXTERN
>> predicate which is held in lang_flag_6 for the c++ frontend. But im not
>> sure about plain c.
>>>>
>>>> At which pass should this be examined?
>>>
>>> The name is handled entirely in the frontend.  I don't think there is
>>> anything in the tree structure that tells you that the variable got a
>>> mangled name.  That kind of information is C++ frontend specific.
>> Hi>
>>
>> would be interesting to see where the mangled name travels along until
>> the linker stage is reached. In the xxx.tu dumps there is clearly a node
>> holding the mangled name.
>>
>> Basically i try to find occurences of silent link-time clashes.
>> say lib1.so exports int global;
>> and lib2.so also exports int global;
>>
>> Linking these two together to a main module, you will end up with one
>> instance of int global (intentionally or not).
>> If there is no shared information via "extern int global;" between say
>> headers of lib1 / lib2 and main module the compiler is not able to
>> detect the situation and there is no warning. The linker will simply
>> assume them as one. (only in the case of not linking shared objects but
>> static libs this is detected by the linker)
>>
>> Making them "static" will prevent that, because each of them is then
>> meant to be "module global" and will be exported under different names.
>>
>> So far for my theory.
>> It gets even worse if the globals have Ctors/dtors and internal memory /
>> handle allocation. They get called twice and may cause double free
>> disasters.
>> I can provide a simple test case if you want to.
> 
> 
> Please reply to the mailing list, not just to me.  Thanks.

sorry for that - wasn't my intention. Also sorry for the fullquote
above, but otherwise the list would miss it.
> 
> See the -fno-common option.
> 
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).

Regards