[PATCH] COFFObjectFile imports fix for compressed binaries

[Bandzi Michal via llvm-commits]

To close this I prepared 3 patches for removed LUT problem. I will  
leave the final decision to you.

removed_lut_fix_1.diff
My first proposed solution. Uses primarily LUT, as it gets never  
overwritten. When LUT is missing IAT is used instead.
Advantages: robust.
Disadvantages: little bit more complicated.

removed_lut_fix_2.diff
Your idea to ignore LUT and use IAT all the time. This should work in  
99,9999% cases. I checked over 10k binaries and IAT does not get  
removed.
Advantages: very simple, should work (for now).
Disadvantages: IAT may be a problem - overwritten or removed, we  did  
not find such a binary yet though.

removed_lut_fix_3.diff
Same as second solution, but it is also contains iterators and range  
for LUT as alternative.

We will be happy with all of them (until some binary with problematic  
IAT appears).

Michal Bandzi

> On Mon, Jul 4, 2016 at 9:52 PM, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Jul 4, 2016 at 2:10 PM, Bandzi Michal <xbandz00 at stud.fit.vutbr.cz>
>> wrote:
>>
>>> Unless I made some logical error I can't see, it should work that way,
>>> doesn't it?
>>>
>>> if (lookupTable)
>>>   return func(lookupTable, ...)
>>> return func(addressTable, ...)
>>
>>
>> I was trying to suggest that we ignore the lookup table case and just do:
>>   return func(addressTable, ...)
>>
>
>
> Thinking about it some more... Let's just have two sets of functions, one
> for the lookupTable and one for the addressTable.
> Let's let the caller decide what information they are interested in :)
>
>
>>
>>
>>>
>>>
>>> I wonder if we should just rely on the ImportAddressTableRVA instead of
>>>> first trying to use the ImportLookupTableRVA.
>>>>
>>>> What are your thoughts?
>>>>
>>>> On Mon, Jul 4, 2016 at 11:05 AM, Bandzi Michal <
>>>> xbandz00 at stud.fit.vutbr.cz>
>>>> wrote:
>>>>
>>>> Cituji David Majnemer <david.majnemer at gmail.com>:
>>>>>
>>>>> Please clang-format the changes in your patch.
>>>>>
>>>>>>
>>>>>>
>>>>> Not sure what exactly this means. Found and used this:
>>>>>
>>>>> http://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>>>>> then created a new patch
>>>>>
>>>>> Also, LLVM does not use else after a return:
>>>>>
>>>>>> http://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return
>>>>>>
>>>>>>
>>>>> Hope this is better. New patch as attachement.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: removed_lut_fix_1.diff
Type: text/x-patch
Size: 1871 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160711/0c999222/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: removed_lut_fix_2.diff
Type: text/x-patch
Size: 1415 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160711/0c999222/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: removed_lut_fix_3.diff
Type: text/x-patch
Size: 2932 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160711/0c999222/attachment-0002.bin>