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 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 ? >>>> >>> On this topic, we should come up with standard file extension names. I >>> made up .objtxt for atoms-in-yaml when writing the first test cases. We >>> will soon need extensions for other kinds of yaml files (such as mach-o in >>> yaml). With linker scripts we are stuck with there being no magic at the >>> start and no standard file extension. For new yaml files that we are >>> inventing we should define a standard file extension. >>> >> 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 file magic compared to using file extension? You would also be able to figure out if the yaml file is a valid input for>> the flavor/target too. >> > > Ping ? > > > Shankar Easwaran > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131009/7dae3ab5/attachment.html>
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 file magic compared to using file extension? > >I would like to support usecases like this. (a) $ cat simple.s .text .global _start .type _start, at function _start: callq bar ret clang simple.s -c- -o- | lld -flavor gnu -target x86_64 --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - Which is certainly not doable because you dont have a file created on the filesystem. PS: This has been snipped from an earlier discussion with Tim. (b) lld -flavor gnu -target x86_64 input.o --output-filetype=yaml -o atoms.objtxt (Create a atom file using x86_64 target) lld -flavor gnu -target hexagon atoms.objtxt (use it with hexagon) You can create yaml files from each flavor and pass it to the wrong flavor, too. If we have the magic and arch in the yaml file (or) one entry combined triple(that combines flavor, operating system and target) this would work and there is no need to create new types of extensions. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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 don't want >> to >> use .txt for YAML object file for example), so what do you think is the >> benefit of depending on special file magic compared to using file >> extension? >> >> >> I would like to support usecases like this. > > (a) > $ cat simple.s > .text > .global _start > .type _start, at function > _start: > callq bar > ret > > clang simple.s -c- -o- | lld -flavor gnu -target x86_64 > --output-filetype=yaml -r - | lld -flavor gnu -target x86_64 - > > Which is certainly not doable because you dont have a file created on the > filesystem. >This is an interesting example but I doubt the actual value of doing that, especially because it cannot handle multiple input files. An alternative command line would be lld -flavor gnu -target x86_64 <(clang simple.s -c- -o- | lld -flavor gnu -target x86_64 --output-filetype=yaml -r -) which could handle multiple inputs, but it works only on bash and may be too tricky. The compiler usually depends on the file extension to distinguish file type, and your file has a non standard file extension, you can explicitly specify the language type by -x*language* option. Adding a similar option to the linker would be an option for us too. Even if we go with a magic, I'd like to make it a simple magic comment, such as "#!obj" at the beginning of a file. A magic string which is valid as a YAML, such as "magic:" is IMO less flexible and should be avoided.> PS: This has been snipped from an earlier discussion with Tim. > > (b) > > lld -flavor gnu -target x86_64 input.o --output-filetype=yaml -o > atoms.objtxt (Create a atom file using x86_64 target) > lld -flavor gnu -target hexagon atoms.objtxt (use it with hexagon) > > You can create yaml files from each flavor and pass it to the wrong > flavor, too. > > If we have the magic and arch in the yaml file (or) one entry combined > triple(that combines flavor, operating system and target) this would work > and there is no need to create new types of extensions. > > > Thanks > > Shankar Easwaran > > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131010/cbb9f776/attachment.html>