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

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>

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>

On Wed, Apr 2, 2014 at 7:47 AM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> 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.
Moreover, inside MIPS architecture there are some incompatible
"sub-architectures". It would be nice if we can check input files and
reject incorrect combinations.

-- 
Simon Atanasyan