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

[Sean Silva]

On Wed, Oct 9, 2013 at 4:09 PM, Nick Kledzik <kledzik at apple.com> wrote:

> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
> > 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 ?
>
> On this topic, we should come up with standard file extension names.  I
> made up .objtxt for atoms-in-yaml when writing the first test cases.  We
> will soon need extensions for other kinds of yaml files (such as mach-o in
> yaml).   With linker scripts we are stuck with there being no magic at the
> start and no standard file extension.  For new yaml files that we are
> inventing we should define a standard file extension.
>

There are a handful of common ones. Checking if the name contains `.lds` or
`.ldscript` would probably cover most of the use cases. On the other hand,
GNU ld's behavior is to assume that anything that isn't recognized as a
binary object file (which are presumably identified by magic) is a linker
script, and we probably want to emulate that behavior (certainly we don't
want to assume that something passed to a GNU ld driver is YAML, unless
explicitly told so via a flag not present in GNU ld).

-- Sean Silva


>
> I agree with Rui that we should not be calling identify_magic() in every
> reader.  Another approach is to just call each reader to try to parse until
> one succeeds.  The first reader should be the native reader (e.g. ELF or
> mach-o), so that in the real world there is no time wasted looking at test
> case formats.
>
> -Nick
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131011/e071bb3c/attachment.html>