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

[Shankar Easwaran]

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