similar to: [LLVMdev] [lld] Handling a whole bunch of readers

On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > 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

All files cannot be identified with a magic though. For example Linker scripts, and currently YAML files. On 10/9/2013 1:36 PM, Rui Ueyama wrote: > I guess in each isMyFormat(), you would check the given file's magic using > llvm::sys::fs::identify_magic(), and then check if it's a known value for > that reader. That would be repeated in each isMyFormat(), which is not very >

On 10/9/2013 3:09 PM, Nick Kledzik wrote: > On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> 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.

I guess in each isMyFormat(), you would check the given file's magic using llvm::sys::fs::identify_magic(), and then check if it's a known value for that reader. That would be repeated in each isMyFormat(), which is not very good. I'd do that using a mapping from file magic to reader. I mean, we could call identify_magic() at some central place, look up the mapping, and then dispatch.

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

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

On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> 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

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

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

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

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

On Wed, Oct 9, 2013 at 7:57 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > >> On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> >>> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> >>> wrote: >>> >>>> We have a whole bunch of readers(we would have

# is a line comment chracter in YAML so it's valid. That's why I wrote a simple magic "comment". On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/10/2013 5:00 PM, Rui Ueyama wrote: > >> On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On

Ah Sorry. Totally forgot about that. On 10/10/2013 8:24 PM, Rui Ueyama wrote: > # is a line comment chracter in YAML so it's valid. That's why I wrote a > simple magic "comment". > > > On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/10/2013 5:00 PM, Rui Ueyama wrote: >> >>> On Thu,

So I talked with Shankar on IRC on this topic, and here's a suggestion. 1. Use a magic comment to determine if it's a YAML file. I'd propose "#!obj" as a YAML file magic because of similarity of Unix shebang. YAML reader skips this first line because it's a comment line in YAML grammar. 2. Add "target" field to YAML to represent what machine type the object

On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/9/2013 11:19 PM, Rui Ueyama wrote: > >> >> Isnt having a YAML file starting with the below better, so that you dont >> need to go through file extensions. >> >> magic : >> arch: >> >> I guess we will use a fixed file extension anyway (we probaly

On 10/10/2013 5:00 PM, Rui Ueyama wrote: > On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> On 10/9/2013 11:19 PM, Rui Ueyama wrote: >> >>> Isnt having a YAML file starting with the below better, so that you dont >>> need to go through file extensions. >>> >>> magic : >>> arch:

On 10/9/2013 11:19 PM, Rui Ueyama wrote: > > Isnt having a YAML file starting with the below better, so that you dont > need to go through file extensions. > > magic : > arch: > > I guess we will use a fixed file extension anyway (we probaly don't want to > use .txt for YAML object file for example), so what do you think is the > benefit of depending on special

Hi, Right now, linker added symbols specified by the -u option do not endup in the output YAML file. This is because the target specific Writers dont get called, which creates the undefined atoms. I am in the process of adding more options and I would like the atoms created internally by the options available in the output YAML file. The options that I am trying to consider for the linker

I'm not planning to remove YAML. YAML is important for testing. On Fri, Feb 6, 2015 at 3:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am fine with it. I hope you are not planning to remove YAML. > > > On 2/6/2015 4:54 PM, Rui Ueyama wrote: > > Can we remove Native format support? I'd like to get input from anyone who > wants to keep the