<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>> <span style="font-family: Calibri, Arial, Helvetica, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">By "all" I presume you mean "all fields that refer </span><span style="font-family: Calibri, Arial, Helvetica, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">to
section counts or indexes".</span></p>
<p><br>
</p>
<p>Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could be redirected to section #0.</p>
<p><br>
</p>
<div id="Signature">
<p>Sent from <a href="http://aka.ms/weboutlook" id="LPNoLP">Outlook</a><br>
</p>
</div>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Pavel Labath <labath@google.com><br>
<b>Sent:</b> Monday, January 23, 2017 2:04 AM<br>
<b>To:</b> Eugene Birukov<br>
<b>Cc:</b> LLDB<br>
<b>Subject:</b> Re: ELF header does not hold big modules</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hello Eugene,<br>
<br>
On 21 January 2017 at 00:42, Eugene Birukov <eugenebi@hotmail.com> wrote:<br>
> Hello,<br>
><br>
><br>
> I have a core dump that LLDB cannot open because it contains more than 64K<br>
> sections. The "readelf" utility gives me the output in the end of this<br>
> message. It seems that the actual number of program headers and the index of<br>
> string table section are written into very first section since they do not<br>
> fit in 16 bits.<br>
><br>
><br>
> The "natural" way to deal with this problem would be to change the types of<br>
> fields in ELFHeader struct from 16 to 32 bits (or should I go all the way<br>
> and do it 64? in case the core dump is bigger than 4GB...) and deal with<br>
> the problem in a single place where we parse the header - the<br>
> ELFHeader::Parse().<br>
><br>
><br>
> Objections? Suggestions? Advices?<br>
<br>
Sounds like a plan. By "all" I presume you mean "all fields that refer<br>
to section counts or indexes". I don't see a reason the change the<br>
size of the e.g. e_type field. I think going 32 bit will be enough,<br>
particularly as the "fallback" field you are reading this from is only<br>
32 bit wide anyway, and so you would still have to touch this if we<br>
ever cross that boundary. (And we are really talking about 4 billion<br>
sections, not a 4GB core file, right?)<br>
<br>
<br>
> Hmm... I am not sure that the DataExtractor we pass down there would let me<br>
> read that much past in the file - I have impression that we give only first<br>
> 512 bytes there, but I might be mistaken...<br>
<br>
The reason we initially read only the first few bytes of the file, is<br>
to be able to make a quick decision as to whether this is likely to be<br>
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in<br>
GetModuleSpecifications). After that, we extend the buffer to the<br>
whole file. It looks like this currently happens before parsing the<br>
ELF header, but I don't see a reason why it would have to stay that<br>
way.<br>
<br>
cheers,<br>
pavel<br>
</div>
</span></font></div>
</div>
</body>
</html>