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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/3390d541/attachment.html>
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. Dean F. Sutherland dsutherland at cert.org<mailto:dsutherland at cert.org> On Oct 15, 2013, at 11:32 AM, Sean Silva <chisophugis at gmail.com<mailto:chisophugis at gmail.com>> wrote: On Mon, Oct 14, 2013 at 11:33 PM, Shankar Easwaran <shankare at codeaurora.org<mailto: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<mailto:bigcheesegs at gmail.com>>wrote: On Wed, Oct 9, 2013 at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org<mailto: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<mailto: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/e34c37c7/attachment.html>
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>