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>
Shankar Easwaran
2014-Apr-02 04:47 UTC
[LLVMdev] [lld] Verifying the Architecture of files read
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>
Simon Atanasyan
2014-Apr-02 04:51 UTC
[LLVMdev] [lld] Verifying the Architecture of files read
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