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

[Rui Ueyama]

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>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>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/81ef56da/attachment.html>