<div dir="ltr">Committed in r280147</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 6, 2016 at 10:58 AM, Bandzi Michal <span dir="ltr"><<a href="mailto:xbandz00@stud.fit.vutbr.cz" target="_blank">xbandz00@stud.fit.vutbr.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cituji David Majnemer <<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>>:<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Aug 1, 2016 at 7:23 AM, Bandzi Michal <<a href="mailto:xbandz00@stud.fit.vutbr.cz" target="_blank">xbandz00@stud.fit.vutbr.cz</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should we make getNumberOfSymbols return 0 if there is no symbol table?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
I was thinking about it when working on the patch and there are two things<br>
to it:<br>
<br>
1) Someone just wants to read field NumberOfSymbols. In this case it<br>
should not be changed.<br>
<br>
2) Somone wants to use that information in let's say for cycle. In this<br>
case it it will cause problems.<br>
<br>
I was unsure about it so I did not change it. Checking COFFObjectFile<br>
interface again, there are two functions for symbol table:<br>
uint32_t getPointerToSymbolTable - returns information as is.<br>
uintptr_t getSymbolTable - returns ptr or 0.<br>
<br>
So maybe something similar could be done?<br>
uint32_t getNumberOfSymbols returns information as is.<br>
size_t getSymbolCount -returns count or 0.<br>
</blockquote>
<br>
<br>
How about getNumberOfSymbols which would return 0 and getRawNumberOfSymbols<br>
which returns whatever is on disk?<br>
<br>
</blockquote></span>
Sounds reasonable. Patch as attachment.<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jul 28, 2016 at 7:46 AM, Bandzi Michal via llvm-commits <<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
<br>
Hello,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When binaries are compressed by UPX, information about symbol table<br>
offset<br>
and symbol count remain unchanged (but became invalid due to<br>
compression).<br>
This causes failure in constructor and rest of the binary cannot be<br>
processed.<br>
<br>
In proposed patch (attachment), when symbol table initialization fails,<br>
constructor does not return error, but rather resets symbol related<br>
information (symbol/string table pointers, sizes) - this should disable<br>
related iterators and function while rest of the binary can be processed.<br>
<br>
Michal Bandzi<br>
<br>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div>