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

[Eugene Birukov via lldb-dev]

Yes, that's what happens to all 3 fields. I already fixed LLDB, Pavel reviewed the change.


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


________________________________
From: Greg Clayton <gclayton at apple.com>
Sent: Thursday, February 2, 2017 2:31 PM
To: Eugene Birukov
Cc: Pavel Labath; LLDB
Subject: Re: [lldb-dev] ELF header does not hold big modules

Found this on the web:


e_shnum
    This member holds the number of entries in the section header
    table. Thus the product of e_shentsize and e_shnum gives the section
    header table's size in bytes. If a file has no section header table,
    e_shnum holds the value zero.

    If the number of sections is greater than or equal to SHN_LORESERVE
    (0xff00), this member has the value zero and the actual number of
    section header table entries is contained in the sh_size field of
    the section header at index 0. (Otherwise, the sh_size member of the
    initial entry contains 0.)


See the second paragraph. I am guessing the same thing would need to happen for program headers? I would check the various ELF file parsers in LLVM and see if they handle this correctly?

Greg

On Jan 23, 2017, at 3:26 PM, Eugene Birukov via lldb-dev <lldb-dev at lists.llvm.org<mailto:lldb-dev at lists.llvm.org>> wrote:

> 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<mailto: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<mailto: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
_______________________________________________
lldb-dev mailing list
lldb-dev at lists.llvm.org<mailto:lldb-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170203/dd199af2/attachment.html>