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

Shankar Easwaran shankare at codeaurora.org
Mon Oct 14 20:33:15 PDT 2013


On 10/14/2013 8:20 PM, Sean Silva wrote:
> On Mon, Oct 14, 2013 at 8:41 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:
>
>> On Wed, Oct 9, 2013 at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org
>>> wrote:
>>> Hi,
>>>
>>> We have a whole bunch of readers(we would have some more too), and was
>>> thinking if we should have a vector of Readers, and have a function
>>> isMyFormat in each of them.
>>>
>>> Any reader that knows to handle, goes ahead and parses the file.
>>>
>>> On a side note, we currently use .objtxt as an figure out if the file is
>>> a YAML file or not. I have added FIXME's in the code, if we could some kind
>>> of magic (or) a better way to figure out if the file is YAML ?
>>>
>>> Thanks
>>>
>>> Shankar Easwaran
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>> by the Linux Foundation
>>>
>>>
>> So apparently I didn't reply all when I suggested this.
>>
>> For determining which YAML reader to use, we should use YAML tags. This
>> allows multiple different types of input files in a single YAML stream.
Agree.
>> !archive
>> <blah>
>> ---
>> !ELF
>> <blah>
>> ---
>> !atoms
>> <blah>
I think <blah> has to be a key value pair here, which could be 
represented as target:<triple>
>>
>> For differentiating between linker scripts and YAML, I agree that some
>> form of comment magic is best.
#!lld ? As lld would be interpreting this file ?

> Since our YAML stuff is all internal anyway, wouldn't it be simpler to just
> hardcode the limited set of extensions we use for YAML files, and only do
> that with non-emulated drivers unless explicitly asked to do so?
That model would be difficult to maintain and we already have the YAML 
file as a avaialable form of an external output file (output-filetype=yaml).

On a sidenote, All of the readers would have a validation function that 
would check the architecture, which makes extensions highly unmanageable.

Thanks

Shankar Easwaran



More information about the llvm-dev mailing list