r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

Sean Silva silvas at purdue.edu
Thu Jan 9 13:12:38 PST 2014

On Thu, Jan 9, 2014 at 12:49 PM, Alp Toker <alp at nuanti.com> wrote:

> OK, sorry I only just got round to this. Backed out in r198884 and r198885.
> In principle it's OK to re-land this with the ifdef Jordan suggested, but
> I think it'd be more sustainable to try using non-reserved identifiers for
> the library part of the sanitizer interface if you have time to look into
> that.

I'm not sure if you're aware of this Alp, but using a reserved "weak"
symbol is a classic and widely used way to expose "hooks" into runtime

__libc_malloc_dispatch in bionic libc

The alternative is usually a function called by the user code in main() or
whatever, which takes a function pointer.

-- Sean Silva

> Cheers
> Alp.
> On 09/01/2014 17:52, Jordan Rose wrote:
>> On Jan 9, 2014, at 9:42 , Alp Toker <alp at nuanti.com <mailto:
>> alp at nuanti.com>> wrote:
>>> On 09/01/2014 17:30, Jordan Rose wrote:
>>>> On Jan 9, 2014, at 6:57 , Alp Toker <alp at nuanti.com <mailto:
>>>> alp at nuanti.com><mailto:alp at nuanti.com>> wrote:
>>>>  I'm not making an assertion. The standard is very clear on this:
>>>>>    * Reserved names [reserved.names]*
>>>>>    If a program declares or defines a name in a context where it is
>>>>>    reserved, other than as explicitly allowed by this Clause, its
>>>>>    *behavior is undefined*.
>>>>>    * Global names [global.names]*
>>>>>    Certain sets of names and function signatures are always reserved
>>>>>    to the implementation:
>>>>>      * *Each name that contains a double underscore __*or begins
>>>>>        with an underscore followed by an uppercase letter (2.12) *is
>>>>>        reserved to the implementation for any use*.
>>>>>      * Each name that begins with an underscore is reserved to the
>>>>>        implementation for use as a name in the global namespace.
>>>> I know I shouldn't be getting into this, but...
>>>>    *1.3.24 undefined behavior [defns.undefined]*
>>>>    behavior for which this International Standard imposes no
>>>> requirements
>>>>    /[ Note: Undefined behavior may be expected when this
>>>>    International Standard omits any explicit definition of behavior
>>>>    or when a program uses an erroneous construct or erroneous data.
>>>>    *Permissible undefined behavior* ranges from ignoring the
>>>>    situation completely with unpredictable results, *to behaving
>>>>    during translation or program execution in a documented manner
>>>>    characteristic of the environment* (with or without the issuance
>>>>    of a diagnostic message), to terminating a translation or
>>>>    execution (with the issuance of a diagnostic message). Many
>>>>    erroneous program constructs do not engender undefined
>>>>    behavior; they are required to be diagnosed. — end note ]/
>>>> (emphasis mine)
>>>> As I read this, a valid interpretation of this program is that when
>>>> LEAK_SANITIZER is defined, the program contains undefined behavior, and
>>>> therefore it should only be set in a context when the particular
>>>> implementation is known to do something sensible for this particular
>>>> undefined behavior (that is, use the function at runtime to disable leak
>>>> checking).
>>>> I don't see this as abstractly different from the standard-specified
>>>> practice of replacing the global operator new, so I don't think it's
>>>> inherently an anti-pattern. I think everyone agrees on this since you've
>>>> said already you'd have no objections if the name weren't one of the
>>>> restricted [global.names] names.
>>>> Would it help if the function were pre-declared in a system header, and
>>>> then just implemented or not implemented in user code?
>>> Hi Jordan,
>>> That's the current situation -- as long as sanitizer headers are
>>> available and in use the part of the spec you highlighted means it's
>>> acceptable.
>>> The problem arises when sanitizer headers aren't available.
>> I just don't think the program is illegal when LEAK_SANITIZER is not
>> defined. The tokens within the #ifdef are skipped completely, so they don't
>> refer to names and certainly don't declare anything.
>> I'm not sure we should care about the case where LEAK_SANITIZER is
>> defined in an environment that doesn't specify what defining this
>> particular name will do. The user has full control over this. (And in fact,
>> IIRC being able to define macros on the command line isn't at all specified
>> by the standard, so the program by itself will /always/ skip the
>> Jordan
> --
> http://www.nuanti.com
> the browser experts
> _______________________________________________
> 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/20140109/0161a1f1/attachment.html>

More information about the cfe-commits mailing list