llvm dev - Apr 2014 - [LLVMdev] [lld] Verifying the Architecture of files read

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

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

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>