This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Summary ======= Extended Numbering is an ELF extension specified in order to cover a lack of field size for some fields of ELF header. Concretely, they are e_phnum, e_shnum and e_shstrndx, which have only 4 byte length in either 32- or 64-bit environments. Sun's document and AMD64 ABI Draft describe the ELF extension. You can reach them from Reference in the bottom of the message. Currently, readelf and libbfd library have implemented the Extended Numbering for e_shnum and e_shstrndx fields but not yet for e_phnum field. The purpose of the patch set is to implement the Extended Numbering for e_phnum field, which is important particularly for ELF object as corefile. Compatibility Concern ===================== * Accorinding to Sun's document, Solaris OS produces ELF corefile conforming to the ELF extension. The activity of applying the patch set to Linux is now in progress. Linux will soon change to produce the extended ELF core object file. Currently, the patch set is in mmotm tree. * There are four combinations according to whether OS and ELF maniplating tools are respectively modified or not. The next table summarizes shortly for each combination. --------------------------------------------- Original OS | Modified OS --------------------------------------------- < 65535 | >= 65535 | < 65535 | >= 65535 ------------------------------------------------------------- Original Tools | OK | broken | OK | broken (#) ------------------------------------------------------------- Modified Tools | OK | broken | OK | OK ------------------------------------------------------------- Note that there is no case that `OK' changes to `broken'. (#) Although this case remains broken, O-M behaves better than O-O. That is, while in O-O case e_phnum field would be extremely small due to integer overflow, in O-M case it is guaranteed to be at least 65535 by being set to PN_XNUM(0xFFFF), much closer to the actual value than the O-O case. How to fix ========== The required code change is part of parsing ELF object format and reading the number of actual program headers according to e_phnum field, which is similar to the one according to e_shnum and e_shstrndx fields that are already implemented. I wrote this by following the similar part for e_shnum and e_shstrndx fields. The reading process proceeds as follows. First, we introduce a new constant PN_XNUM which is defined to be 0xFFFF. The place where the number of actual program headers is located varies according wheather e_phnum field is PN_XNUM or not. Let n be the value of e_phnum field of the ELF object file. Then, - if n < PN_XNUM, then the n is the number of program headers. - if n == PN_XNUM, then the number of program headers is located in sh_info field of the section header at index 0. Patch ===== * The patch set comprises of three patches. [PATCH 1/3] introduces PN_XNUM, [PATCH 2/3] modifies readelf, and [PATCH 3/3] modifies libbfd library. * Tested on x86-64. readelf and objdump work well. * diff stat output for a whole patch set fd/elfcore.h | 56 -------------------------------------------------- binutils/readelf.c | 7 +----- include/elf/common.h | 3 -- 3 files changed, 1 insertions(+), 65 deletions(-) Question ======== Do I need to submit the similar patch set to GDB community? Of course I need to submit a similar patch set to GDB community, but GDB also uses libbfd library to manipulate ELF object file. Reference ========= - Sun microsystems: Linker and Libraries. Part No: 817-1984-17, September 2008. URL: http://docs.sun.com/app/docs/doc/817-1984 - System V ABI AMD64 Architecture Processor Supplement Draft Version 0.99., May 11, 2009. URL: http://www.x86-64.org/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |