[LLVMdev] [lld] Verifying the Architecture of files read

[Shankar Easwaran]

Ruiu,

I am not sure if you looked at this thread 
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066155.html)

let me know if you still have questions.

As a short summary, we dont verify the architecture of files that are 
being read. We could very well be passed in a hexagon input file while 
the target specified was x86_64. we got to reject the input file as the 
user has chosen the architecture to be x86_64.

Thanks

Shankar Easwaran

On 4/1/2014 11:34 PM, Rui Ueyama wrote:
> Could you elaborate a bit about the issue that you are trying to solve 
> with this suggestion?
>
>
> On Tue, Apr 1, 2014 at 9:27 PM, Shankar Easwaran 
> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote:
>
>     Hi Nick, Bigcheese,
>
>     Resurrecting a old thread.
>
>     Now since we have a Registry that models Readers, do we want to
>     have a function in the Registry that evaluates whether a file
>     should be parsed into atoms (or) raise an appropriate error ?
>
>     I would think the output architecture could be chosen from the
>     first file that was parsed, I think each flavor's LinkingContext
>     should store a field pointing to the architecture of the first
>     input file that was tried to be parsed.
>
>     Thanks
>
>     Shankar Easwaran
>
>
>     On 10/7/2013 3:50 PM, Shankar Easwaran wrote:
>
>         On 10/7/2013 3:23 PM, Nick Kledzik wrote:
>
>             On Oct 4, 2013, at 8:50 PM, Shankar Easwaran
>             <shankare at codeaurora.org <mailto:shankare at codeaurora.org>>
>             wrote:
>
>                 It is needed that lld verifies the input to the linker.
>
>                 For example : a x86 ELF file can be given to lld when
>                 the target is x86_64. Similiarly with other flavors.
>
>                 I was thinking to have a varargs function in the
>                 LinkingContext that would be overridden by each of the
>                 LinkingContexts to verify files after being read.
>
>                 The reader would call the varargs function in the
>                 LinkingContext and raise an error if the input is not
>                 suitable with the current link mode.
>
>             Yes.  We need a way to error out if there is an
>             architecture mismatch.  But there are some interesting
>             scenarios we need to support.
>
>         Ok. will create a varArg function (verifyArch ?)
>
>         I am trying to see if variadic functions would be another
>         alternative too.
>
>             * If linking with a static library, you may not know until
>             you actually need to load one of the members if the
>             architecture is wrong, and it may not be an error if the
>             architecture is wrong, but nothing is loaded.
>
>             * It might be a warning instead of an error to link
>             against a shared library of the wrong architecture.  That
>             is, the linker may need to ignore (and warn) but continue
>             and try to complete the link without it.
>
>             * The mach-o linker also allows you to not specify the
>             architecture on the command line.  Instead the linker
>             infers the architecture by looking at the first object
>             file.  This is mostly used in -r mode.  So, where the
>             check is done to see that the arch is correct, may
>             actually cause the architecture in the LinkingContext to
>             be set.
>
>         For lld, I think the flavor also would need to be inferred
>         from the first object, isnt it ?
>
>
>             * mach-o also has “fat” files which can contain multiple
>             architectures.  So, the reader needs to know the arch to
>             even try to parse.  In other words, if the Reader is told
>             the intended arch, the Reader could error out if the file
>             is not of that arch (and for mach-o the Reader would
>             select the right slice in a fat file).
>
>         Since all of the code ends up within the parseFile function in
>         the Reader, we should be able to query LinkingContext and
>         return an actual error/warning on a need basis and only on
>         valid scenarios.
>
>         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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/bc214416/attachment.html>