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

[Shankar Easwaran]

On 10/7/2013 5:13 PM, Michael Spencer wrote:
> On Sun, Oct 6, 2013 at 7:38 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:
>
>> On 10/4/2013 11:16 PM, Michael Spencer wrote:
>>
>>> On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org
>>>> **wrote:
>>>   Hi,
>>>> 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.
>>>>
>>>> Thanks
>>>>
>>>> Shankar Easwaran
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>>> by the Linux Foundation
>>>>
>>>>
>>>>   Why would it need to be varargs?
>> LinkingContext for ELF would require fields from the ELF header to verify
>> if the file thats being read belongs to the current target architecture.
>>
>> I am not sure of how many fields would determine the same for Darwin and
>> COFF.
>>
>> This is the reason I thought it should be varargs.
>
> The reader has an {ELF,COFF,Darwin}LinkingContext. It can just ask the
> context.
This would make it not part of the LinkingContext interface then. I was 
thinking of a pure virtual function defined in LinkingContext and all
LinkingContexts to implement the function in their code.
> Specifically this would be a good place to use the user data part of
>>> ErrorOr to specify what was expected and what was received.
>>>
>> Couldnt follow this. Can you elaborate ?
>
> ErrorOr supports user data. See unittests/Support/ErrorOrTest.cpp.
>
> It would simply be: return ArchMismatch(expected, actual);
>
> Then an error handler higher up can extract that to form a proper error
> message.
Ok.

Thanks

Shankar Easwaran