From 3444ed7cf1118f3f288bc6941c8e726f732ad8c6 Mon Sep 17 00:00:00 2001 From: "mark@chromium.org" Date: Mon, 6 May 2013 19:53:48 +0000 Subject: Fix GetLoadingAddress() to work for Native Client executables NaCl executables have ELF program headers that look like this (for the original NaCl x86 GCC toolchain): Program Header: LOAD off 0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16 filesz 0x00017ce0 memsz 0x00017ce0 flags r-x LOAD off 0x00030000 vaddr 0x10020000 paddr 0x10020000 align 2**16 filesz 0x00001c98 memsz 0x00001c98 flags r-- LOAD off 0x00040000 vaddr 0x10030000 paddr 0x10030000 align 2**16 filesz 0x000025ec memsz 0x00002b88 flags rw- or this (for the newer NaCl ARM GCC toolchain): Program Header: LOAD off 0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16 filesz 0x000193b0 memsz 0x000193b0 flags r-x LOAD off 0x00000000 vaddr 0x10020000 paddr 0x10020000 align 2**16 filesz 0x00000978 memsz 0x00000978 flags r-- LOAD off 0x00001000 vaddr 0x10031000 paddr 0x10031000 align 2**16 filesz 0x00000abc memsz 0x00000fac flags rw- Fix GetLoadingAddress() to return the start address of the first segment, 0x20000, in these cases. Looking at p_offset for this isn't correct, and the first segment doesn't have p_offset == 0 here because NaCl can't map the ELF file headers as part of the first segment (which is for validatable code only). BUG= https://code.google.com/p/nativeclient/issues/detail?id=3424 TEST= check addresses in output of "dump_syms" when run on NaCl nexe Patch by Mark Seaborn Review URL: https://breakpad.appspot.com/588002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1170 4c0a9323-5329-0410-9bdc-e9ce6186880e --- src/common/linux/dump_symbols.cc | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/common/linux/dump_symbols.cc b/src/common/linux/dump_symbols.cc index 517edee3..014e7c3e 100644 --- a/src/common/linux/dump_symbols.cc +++ b/src/common/linux/dump_symbols.cc @@ -152,14 +152,16 @@ typename ElfClass::Addr GetLoadingAddress( int nheader) { typedef typename ElfClass::Phdr Phdr; + // For non-PIC executables (e_type == ET_EXEC), the load address is + // the start address of the first PT_LOAD segment. (ELF requires + // the segments to be sorted by load address.) For PIC executables + // and dynamic libraries (e_type == ET_DYN), this address will + // normally be zero. for (int i = 0; i < nheader; ++i) { const Phdr& header = program_headers[i]; - // For executable, it is the PT_LOAD segment with offset to zero. - if (header.p_type == PT_LOAD && - header.p_offset == 0) + if (header.p_type == PT_LOAD) return header.p_vaddr; } - // For other types of ELF, return 0. return 0; } -- cgit v1.2.1