[lldb-dev] ELF header does not hold big modules

[Eugene Birukov via lldb-dev]

> By "all" I presume you mean "all fields that refer to section counts or indexes".


Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could be redirected to section #0.


Sent from Outlook<http://aka.ms/weboutlook>


________________________________
From: Pavel Labath <labath at google.com>
Sent: Monday, January 23, 2017 2:04 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: ELF header does not hold big modules

Hello Eugene,

On 21 January 2017 at 00:42, Eugene Birukov <eugenebi at hotmail.com> wrote:
> Hello,
>
>
> I have a core dump that LLDB cannot open because it contains more than 64K
> sections. The "readelf" utility gives me the output in the end of this
> message. It seems that the actual number of program headers and the index of
> string table section are written into very first section since they do not
> fit in 16 bits.
>
>
> The "natural" way to deal with this problem would be to change the types of
> fields in ELFHeader struct from 16 to 32 bits (or should I go all the way
> and  do it 64? in case the core dump is bigger than 4GB...) and deal with
> the problem in a single place where we parse the header - the
> ELFHeader::Parse().
>
>
> Objections? Suggestions? Advices?

Sounds like a plan. By "all" I presume you mean "all fields that refer
to section counts or indexes". I don't see a reason the change the
size of the e.g. e_type field. I think going 32 bit will be enough,
particularly as the "fallback" field you are reading this from is only
32 bit wide anyway, and so you would still have to touch this if we
ever cross that boundary. (And we are really talking about 4 billion
sections, not a 4GB core file, right?)


> Hmm... I am not sure that the DataExtractor we pass down there would let me
> read that much past in the file - I have impression that we give only first
> 512 bytes there, but I might be mistaken...

The reason we initially read only the first few bytes of the file, is
to be able to make a quick decision as to whether this is likely to be
a valid elf file (see call to ObjectFileELF::MagicBytesMatch in
GetModuleSpecifications). After that, we extend the buffer to the
whole file. It looks like this currently happens before parsing the
ELF header, but I don't see a reason why  it would have to stay that
way.

cheers,
pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170123/3d67c6b7/attachment-0001.html>