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

Dean Sutherland dsutherland at cert.org
Wed Oct 16 07:37:22 PDT 2013


Great.  Thanks for clarifying.

Dean

On Oct 15, 2013, at 7:52 PM, Sean Silva <chisophugis at gmail.com<mailto:chisophugis at gmail.com>> wrote:




On Tue, Oct 15, 2013 at 12:01 PM, Dean Sutherland <dsutherland at cert.org<mailto: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<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://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/20131016/c4b3714f/attachment.html>


More information about the llvm-dev mailing list