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