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

[Alexey Samsonov]

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. 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.


>
> (The other solution to this problem that I thought of was to teach the tool
> that builds the special case list to backslash-escape metacharacters and
> then
> teach SpecialCaseList to try to unescape them, but then I realised that
> this
> wouldn't work for the '*' character because we currently replace it with
> '.*'
> which wouldn't be escaped correctly. Although I guess maybe we could say
> that
> '\*' is treated like a literal '*' in the regex, meaning that one could
> write
> '\\*' to match a literal '*'. But maybe so many levels of escaping would be
> too confusing.)
>
> 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/41b10ed2/attachment.html>