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

[Rui Ueyama]

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>