[PATCH] COFFObjectFile imports fix for compressed binaries

[David Majnemer via llvm-commits]

Thanks,

I've applied option #3 in r277298.

On Mon, Jul 11, 2016 at 12:10 PM, Bandzi Michal <xbandz00 at stud.fit.vutbr.cz>
wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160731/a05fd4c7/attachment.html>