[LLVMdev] [lld] Handling a whole bunch of readers

Sean Silva chisophugis at gmail.com
Tue Oct 15 16:52:09 PDT 2013


On Tue, Oct 15, 2013 at 12:01 PM, Dean Sutherland <dsutherland at cert.org>wrote:

>  Here at CERT we've written some prototype tools that use YAML files to
> hold a minimal subset of the Clang parse tree. We then combine these files
> to perform cross-TU static analysis.  We write out *only* the minimal
> information required for the particular static analysis being performed, so
> it's a tiny subset of the entire parse tree.  Of course, that's all a
> hack-around to enable the cross-TU analysis...
>
>  We'd be rather disappointed if the YAML library suddenly (a) started
> supporting a limited set of output file kinds and (b) failed to provide a
> simple mechanism to add custom file kinds to that set.
>

This thread isn't discussing the YAML library itself. Nothing discussed in
this thread would affect the library (besides what Michael said about tags,
which would just increase the conformance of the YAML parser to cover more
of the YAML spec).

-- Sean Silva


>
>  Dean F. Sutherland
> dsutherland at cert.org
>
>  On Oct 15, 2013, at 11:32 AM, Sean Silva <chisophugis at gmail.com>
>  wrote:
>
>
>
>
> On Mon, Oct 14, 2013 at 11:33 PM, Shankar Easwaran <
> shankare at codeaurora.org> wrote:
>
>> On 10/14/2013 8:20 PM, Sean Silva wrote:
>>
>>> On Mon, Oct 14, 2013 at 8:41 PM, Michael Spencer <bigcheesegs at gmail.com
>>> >wrote:
>>>
>>>  On Wed, Oct 9, 2013 at 11:23 AM, Shankar Easwaran <
>>>> shankare at codeaurora.org
>>>>
>>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> We have a whole bunch of readers(we would have some more too), and was
>>>>> thinking if we should have a vector of Readers, and have a function
>>>>> isMyFormat in each of them.
>>>>>
>>>>> Any reader that knows to handle, goes ahead and parses the file.
>>>>>
>>>>> On a side note, we currently use .objtxt as an figure out if the file
>>>>> is
>>>>> a YAML file or not. I have added FIXME's in the code, if we could some
>>>>> kind
>>>>> of magic (or) a better way to figure out if the file is YAML ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Shankar Easwaran
>>>>>
>>>>> --
>>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>>> hosted
>>>>> by the Linux Foundation
>>>>>
>>>>>
>>>>>  So apparently I didn't reply all when I suggested this.
>>>>
>>>> For determining which YAML reader to use, we should use YAML tags. This
>>>> allows multiple different types of input files in a single YAML stream.
>>>>
>>>  Agree.
>>
>>  !archive
>>>> <blah>
>>>> ---
>>>> !ELF
>>>> <blah>
>>>> ---
>>>> !atoms
>>>> <blah>
>>>>
>>>  I think <blah> has to be a key value pair here, which could be
>> represented as target:<triple>
>>
>>
>>>> For differentiating between linker scripts and YAML, I agree that some
>>>> form of comment magic is best.
>>>>
>>>  #!lld ? As lld would be interpreting this file ?
>>
>>
>>  Since our YAML stuff is all internal anyway, wouldn't it be simpler to
>>> just
>>> hardcode the limited set of extensions we use for YAML files, and only do
>>> that with non-emulated drivers unless explicitly asked to do so?
>>>
>>  That model would be difficult to maintain and we already have the YAML
>> file as a avaialable form of an external output file (output-filetype=yaml).
>>
>
>  Do we actually have users that rely on that feature? Is the YAML format
> is stable enough for being exposed to users? It seems unwise to expose what
> is effectively a debug/testing format to users.
>
>  -- Sean Silva
>
>
>>
>> On a sidenote, All of the readers would have a validation function that
>> would check the architecture, which makes extensions highly unmanageable.
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/1c6fd967/attachment.html>


More information about the llvm-dev mailing list