COFFObjectFile ignore broken symbol table

[David Majnemer via llvm-commits]

Committed in r280147

On Sat, Aug 6, 2016 at 10:58 AM, Bandzi Michal <xbandz00 at stud.fit.vutbr.cz>
wrote:

> Cituji David Majnemer <david.majnemer at gmail.com>:
>
> On Mon, Aug 1, 2016 at 7:23 AM, Bandzi Michal <xbandz00 at stud.fit.vutbr.cz>
>> wrote:
>>
>> Should we make getNumberOfSymbols return 0 if there is no symbol table?
>>>
>>>>
>>>>
>>> I was thinking about it when working on the patch and there are two
>>> things
>>> to it:
>>>
>>> 1) Someone just wants to read field NumberOfSymbols. In this case it
>>> should not be changed.
>>>
>>> 2) Somone wants to use that information in let's say for cycle. In this
>>> case it it will cause problems.
>>>
>>> I was unsure about it so I did not change it. Checking COFFObjectFile
>>> interface again, there are two functions for symbol table:
>>> uint32_t getPointerToSymbolTable - returns information as is.
>>> uintptr_t getSymbolTable - returns ptr or 0.
>>>
>>> So maybe something similar could be done?
>>> uint32_t getNumberOfSymbols returns information as is.
>>> size_t getSymbolCount -returns count or 0.
>>>
>>
>>
>> How about getNumberOfSymbols which would return 0 and
>> getRawNumberOfSymbols
>> which returns whatever is on disk?
>>
>> Sounds reasonable. Patch as attachment.
>
>
>>>
>>>
>>> On Thu, Jul 28, 2016 at 7:46 AM, Bandzi Michal via llvm-commits <
>>>> llvm-commits at lists.llvm.org> wrote:
>>>>
>>>> Hello,
>>>>
>>>>>
>>>>> When binaries are compressed by UPX, information about symbol table
>>>>> offset
>>>>> and symbol count remain unchanged (but became invalid due to
>>>>> compression).
>>>>> This causes failure in constructor and rest of the binary cannot be
>>>>> processed.
>>>>>
>>>>> In proposed patch (attachment), when symbol table initialization fails,
>>>>> constructor does not return error, but rather resets symbol related
>>>>> information (symbol/string table pointers, sizes) - this should disable
>>>>> related iterators and function while rest of the binary can be
>>>>> processed.
>>>>>
>>>>> Michal Bandzi
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160830/63d0ff7f/attachment.html>