[(questionable but useful) patch] Let codegen write the filename for translation unit initializer functions

[Reid Kleckner]

Users of ASan's init order checker are ending up confused by _GLOBAL__I_a,
so I guess I'd like to see this go in.  Feel free to commit with some
sanitization of the filename.

On Mon, Apr 28, 2014 at 12:26 PM, Nico Weber <thakis at chromium.org> wrote:

> On Fri, Apr 25, 2014 at 4:33 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> This might give some assemblers heartburn.  Does gcc sanitize the
>> filename in any way?
>>
>
> gcc apparently replaces spaces, '-, '+' etc with '_', so it does some
> sanitizing. ("test$2.cc" ends up being just "test.cc", so their sanitizing
> isn't complete.)
>
> Does LLVM have a helper function that replaces possibly troubling
> characters with '_' characters?
>

Not that I know of.


> What happens if the main source file is stdin?
>>
>
> gcc produces "_GLOBAL__sub_I_" (i.e. "nothing" for stdin). (My patch
> currently adds a "<stdin>", which seems suboptimal :-) ).
>
> gcc apparently only does this in -fPIC mode too, not sure why.
>
>
>>
>> On Fri, Apr 25, 2014 at 4:17 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>>>  Hi,
>>>
>>> gcc calls the static initialization function for file foo.cc
>>> _GLOBAL__sub_i_foo.cc, while clang always uses _GLOBAL__I_a . Having the
>>> filename in the symbol is useful for finding where static initializers are
>>> from; we use this information in chromium on linux. (On Mac, we look at the
>>> dSYM file instead.)
>>>
>>> The attached patch makes clang behave like gcc for initializers. (It
>>> doesn't change the behavior for __D_ functions, not sure if anyone wants
>>> that.)
>>>
>>> Opinions? Is this useful for anyone else?
>>>
>>> (Drawbacks: slightly longer symbols, which has a (small) binary size
>>> cost, and it looks like __attribute__ ((init_priority(101))) works by
>>> naming the _GLOBAL__ functions _GLOBAL__I_000101 etc, so if you call your
>>> source file 000101.cc it might interfere with this patch.
>>>
>>> Nico
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140505/6e560bb4/attachment.html>