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

[Shankar Easwaran]

I like this suggestion proposed by Ruiu. It makes the Reader flexible 
and can use a common infrastructure to verify files too.

Thanks

Shankar Easwaran

On 10/10/2013 10:08 PM, Rui Ueyama wrote:
> 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
>>
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation