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

[Shankar Easwaran]

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