So is for PE32 and PE32+. They cannot be mixed because they are for x86 and x86-64, respectively. I'd think we can simply wait for all files to be parsed and pass them to a LinkingContext to ask whether or not the input file set seems OK. On Tue, Apr 1, 2014 at 9:59 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 4/1/2014 11:51 PM, Simon Atanasyan wrote: > >> 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. >> > For a simple design, I was thinking that the LinkingContext per flavor > could store input file information as its processed by the linker and > choose to reject files or accept them. > > The only problem here is that since the input files are parsed in > parallel, how do we want to deal with this scenario ? > > > 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/339e417e/attachment.html>
Shankar Easwaran
2014-Apr-02 05:16 UTC
[LLVMdev] [lld] Verifying the Architecture of files read
On 4/2/2014 12:06 AM, Rui Ueyama wrote:> So is for PE32 and PE32+. They cannot be mixed because they are for x86 and > x86-64, respectively. > > I'd think we can simply wait for all files to be parsed and pass them to a > LinkingContext to ask whether or not the input file set seems OK.There are pros and cons to your approach :- _*pros*_ a) easier to implement b) lot of usecases that the linker usually deals with, are users specifying the right architecture _*cons*_ a) the input files will need to be looked at again, either the elf header has to be re-read or stored in LinkingContext (increase in memory footprint). b) there might be an issue with just one input file, and the user has to wait till all files have been parsed to get the actual error. c) users use a huge command line linking few applications(example:building clang), and the cost of revisiting all the input files may be huge. I would prefer the architecture be read/verified at the time of reading, and stop reading the rest of the files as soon as we see a discrepancy. If I misunderstood your suggestion, please let me know. 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/20140402/b1b7cb4c/attachment.html>
I'd think my question is whether or not we want to have some sophisticated approach for the situation that a user accidentally give a wrong object file to LLD. If that really happens frequently, and if we really don't want users to wait for the parser to parse all files, we need some solution that works progressively as we read files. I think, in such situation, the most important thing is to correctly raise an error. Response time to raise an error is not that important. On Tue, Apr 1, 2014 at 10:16 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 4/2/2014 12:06 AM, Rui Ueyama wrote: > > So is for PE32 and PE32+. They cannot be mixed because they are for x86 and > x86-64, respectively. > > I'd think we can simply wait for all files to be parsed and pass them to a > LinkingContext to ask whether or not the input file set seems OK. > > There are pros and cons to your approach :- > > *pros* > a) easier to implement > b) lot of usecases that the linker usually deals with, are users > specifying the right architecture > > *cons* > a) the input files will need to be looked at again, either the elf header > has to be re-read or stored in LinkingContext (increase in memory > footprint). > b) there might be an issue with just one input file, and the user has to > wait till all files have been parsed to get the actual error. > c) users use a huge command line linking few applications(example:building > clang), and the cost of revisiting all the input files may be huge. >I don't get (a). Why do you have to scan a file again?> I would prefer the architecture be read/verified at the time of reading, > and stop reading the rest of the files as soon as we see a discrepancy. > > If I misunderstood your suggestion, please let me know. > > > 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/5b0dad05/attachment.html>
Nick Kledzik
2014-Apr-03 01:36 UTC
[LLVMdev] [lld] Verifying the Architecture of files read
It is more than “verify” . Mach-o has “fat” (aka “universal”) files which contain multiple “slices”. Each slice is for a different arch. The Reader needs to know the intended arch up front to pick the right slice. On Apr 1, 2014, at 10:06 PM, Rui Ueyama <ruiu at google.com> wrote:> I'd think we can simply wait for all files to be parsed and pass them to a LinkingContext to ask whether or not the input file set seems OK.Except there is no method on lld::File that returns its “architecture”. We’ve been side stepping the issue of how to model architectures (e.g. triples) in lld. We do need to eventually nail this down because we need to record that info in yaml and native files. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140402/554423e1/attachment.html>
On Wed, Apr 2, 2014 at 6:36 PM, Nick Kledzik <kledzik at apple.com> wrote:> It is more than “verify” . Mach-o has “fat” (aka “universal”) files which > contain multiple “slices”. Each slice is for a different arch. The Reader > needs to know the intended arch up front to pick the right slice. >That's true. Does the linker on Mac knows which architecture that is trying to link prior to handling input files (by a command line flag, environment variable, etc), or does it have to make a decision by reading a few files? (e.g. set the target architecture with the same one as the first file's magic.)> On Apr 1, 2014, at 10:06 PM, Rui Ueyama <ruiu at google.com> wrote: > > I'd think we can simply wait for all files to be parsed and pass them to a > LinkingContext to ask whether or not the input file set seems OK. > > > Except there is no method on lld::File that returns its “architecture”. > > We’ve been side stepping the issue of how to model architectures (e.g. > triples) in lld. We do need to eventually nail this down because we need > to record that info in yaml and native files. > > -Nick > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140402/620d0e20/attachment.html>
Shankar Easwaran
2014-Apr-03 20:00 UTC
[LLVMdev] [lld] Verifying the Architecture of files read
On 4/2/2014 8:36 PM, Nick Kledzik wrote:> It is more than “verify” . Mach-o has “fat” (aka “universal”) files > which contain multiple “slices”. Each slice is for a different arch. > The Reader needs to know the intended arch up front to pick the right > slice. >Currently the GnuLdDriver creates a LinkingContext(X86_64, X86, ....) from the -target option in the Gnu flavor. So here, the driver has to sniff the first file if the -target option is not mentioned in the command-line I think. This would create more problems if the first input file is just a linker script.> > On Apr 1, 2014, at 10:06 PM, Rui Ueyama <ruiu at google.com > <mailto:ruiu at google.com>> wrote: >> I'd think we can simply wait for all files to be parsed and pass them >> to a LinkingContext to ask whether or not the input file set seems OK. > > Except there is no method on lld::File that returns its “architecture”.Are you thinking of lld::File returning a llvm::Triple as in :- llvm::Triple triple() const = 0;> > We’ve been side stepping the issue of how to model architectures (e.g. > triples) in lld. We do need to eventually nail this down because we > need to record that info in yaml and native files. >Agree. 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/20140403/01f9ccce/attachment.html>