# 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 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. >> > YAML only allows key-value pairs. #!obj are all invalid characters for > YAML files. > > >> 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 >>> >>> >>> > > -- > 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/4ddaa754/attachment.html>
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, 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. >>> >> YAML only allows key-value pairs. #!obj are all invalid characters for >> YAML files. >> >> >>> 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 >>>> >>>> >>>> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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 type represents. For example, if a YAML object has "target: x86_64-linux-elf", it's decoded as a x86-64 Linux object file. 3. Let the YAML reader to interpret "target" field to handle target-specific fields if needed. On Thu, Oct 10, 2013 at 7:44 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> 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, 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. >>>> >>>> YAML only allows key-value pairs. #!obj are all invalid characters for >>> YAML files. >>> >>> >>> 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 >>>>> >>>>> >>>>> >>>>> -- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >>> by the Linux Foundation >>> >>> >>> > > -- > 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/6b4b0bee/attachment.html>