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

[Rui Ueyama]

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>