[llvm] r212643 - Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.

Alexey Samsonov vonosmas at gmail.com
Wed Jul 9 17:23:48 PDT 2014


On Wed, Jul 9, 2014 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> On Wed, Jul 09, 2014 at 04:15:42PM -0700, Alexey Samsonov wrote:
> > Hi,
> >
> > On Wed, Jul 9, 2014 at 1:42 PM, Peter Collingbourne <peter at pcc.me.uk>
> wrote:
> >
> > > On Wed, Jul 09, 2014 at 07:40:09PM -0000, Alexey Samsonov wrote:
> > > > Author: samsonov
> > > > Date: Wed Jul  9 14:40:08 2014
> > > > New Revision: 212643
> > > >
> > > > URL: http://llvm.org/viewvc/llvm-project?rev=212643&view=rev
> > > > Log:
> > > > Decouple llvm::SpecialCaseList text representation and its LLVM IR
> > > semantics.
> > > >
> > > > Turn llvm::SpecialCaseList into a simple class that parses text
> files in
> > > > a specified format and knows nothing about LLVM IR. Move this class
> into
> > > > LLVMSupport library. Implement two users of this class:
> > > >   * DFSanABIList in DFSan instrumentation pass.
> > > >   * SanitizerBlacklist in Clang CodeGen library.
> > > > The latter will be modified to use actual source-level information
> from
> > > frontend
> > > > (source file names) instead of unstable LLVM IR things (LLVM Module
> > > identifier).
> > > >
> > > > Remove dependency edge from ClangCodeGen/ClangDriver to
> > > LLVMTransformUtils.
> > > >
> > > > No functionality change.
> > >
> > > Okay.
> > >
> > > Do you have any further refactoring planned for SpecialCaseList? One
> change
> > > that I realised that I will need to make for DFSan is to change the
> > > semantics
> > > for symbol names appearing in the special case list so that they are
> always
> > > interpreted "literally", in order to allow symbol names that may
> contain
> > > regex metacharacters to be added to the StringSet. Of course this
> would be
> > > under a boolean argument somewhere so that the special case list
> semantics
> > > for the other sanitizers aren't affected.
> > >
> >
> > No, I don't currently plan refactoring of SpecialCaseList, instead I'm
> > going change
> > the behavior of SanitizerBlacklist. Literal representation of
> > metacharacters (except for *)
> > sounds like a good idea - documentation refers to special case list
> entries
> > as "wildcard
> > expressions", not "regular expressions", so it would be weird to force
> > users to escape
> > characters on their own.
>
> The patterns are referred to as "regular expressions" here, with examples
> that use RE syntax and specifically refer to the patterns as being EREs:
> http://clang.llvm.org/docs/SanitizerSpecialCaseList.html#format
>
> The examples don't seem particularly compelling to me. If not bound by
> compatibility constraints, I would make '*' the only recognized
> metacharacter.
> Maybe we should add support to SpecialCaseList for a "version 2" of the
> format which only supports '*'?
>

Ah, indeed, I wrote this doc and now forgot about it =/
I'd also vote for making "*" the only metacharacter for simplicity.
However, we can
probably just get away with silently changing it to be the case (and
updating the docs).
I'm not aware of lots of blacklist users relying on the old behavior.


>
> > But, yes, let's make this change affect DFSan only
> > for now,
> > just add  an extra parameter to SpecialCaseList factory to specify if it
> > needs to escape
> > metachars when parsing the file.
>
> OK, sounds good.
>
> Thanks,
> --
> Peter
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140709/76a37438/attachment.html>


More information about the llvm-commits mailing list