From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10132 invoked by alias); 12 Jun 2003 23:12:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10090 invoked from network); 12 Jun 2003 23:12:16 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 12 Jun 2003 23:12:16 -0000 Received: by zenia.home (Postfix, from userid 5433) id 2913220D85; Thu, 12 Jun 2003 18:12:27 -0500 (EST) To: gdb-patches@sources.redhat.com Subject: [ppc64-linux]: correctly find a BFD's code entry point address From: Jim Blandy Date: Thu, 12 Jun 2003 23:12:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00437.txt.bz2 2003-06-12 Jim Blandy * ppc-linux-tdep.c (ppc64_linux_bfd_entry_point): New function. (ppc_linux_init_abi): Register it as our bfd_entry_point address. Index: gdb/ppc-linux-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v retrieving revision 1.28.8.18 diff -c -r1.28.8.18 ppc-linux-tdep.c *** gdb/ppc-linux-tdep.c 12 Jun 2003 21:25:50 -0000 1.28.8.18 --- gdb/ppc-linux-tdep.c 12 Jun 2003 23:11:22 -0000 *************** *** 941,946 **** --- 941,1046 ---- } + /* Return the unrelocated code address at which execution begins for + ABFD, under the 64-bit PowerPC Linux ABI. On that system, the ELF + header e_entry field (which is what bfd_get_start_address gives + you) is the address of the function descriptor for the startup + function, not the address of the actual machine instruction you + jump to. + + This function doesn't just go and read the entry point from the + function descriptor. We need it to work when ABFD is the dynamic + linker, immediately after an exec. But ld.so is a dynamic + executable itself on PPC64 Linux, so it appears in memory whereever + the kernel drops it; this means that bfd_get_start_address's result + needs to be adjusted --- by some offset we don't know. So we can't + find the descriptor's address in memory to read the entry point + from it. + + Instead, we do it all based on ABFD's symbol table. We take the + address from bfd_get_start_address, find each symbol at that + address, stick a '.' on the front of its name to get the entry + point symbol name, try to look that up, and return the value of + what we find, if anything. We never touch memory, or talk with the + kernel about the inferior at all. + + Now, this address we return is straight from the symbol table, so + it hasn't been adjusted to take into account where ABFD was loaded. + But that's okay --- our job is just to return the unrelocated code + address. */ + static CORE_ADDR + ppc64_linux_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd) + { + long storage_needed; + + storage_needed = bfd_get_symtab_upper_bound (abfd); + + if (storage_needed > 0) + { + asymbol **symbol_table; + unsigned int symbol_table_len; + struct cleanup *back_to; + unsigned int i; + CORE_ADDR start_address; + + symbol_table = (asymbol **) xmalloc (storage_needed); + back_to = make_cleanup (xfree, symbol_table); + symbol_table_len = bfd_canonicalize_symtab (abfd, symbol_table); + + /* Find the symbol naming the start function's descriptor. Its + value must be the BFD's start address, and it must be in a + data section. + + Also, the symbol's name must be non-empty. A lot of symtabs + seem to contain a bunch of symbols with no name whose value + is zero relative to the start of the data section; if the + start function descriptor is the first thing in the data + section, we'll get more false positives than we'd like. */ + start_address = bfd_get_start_address (abfd); + for (i = 0; i < symbol_table_len; i++) + if (bfd_asymbol_value (symbol_table[i]) == start_address + && symbol_table[i]->section->flags & SEC_DATA + && bfd_asymbol_name (symbol_table[i])[0] != '\0') + { + /* Okay, we've found a symbol whose value and section are + right. Construct the name of the corresponding entry + point symbol and see if we can find a symbol with that + name in a code section. */ + const char *desc_name = bfd_asymbol_name (symbol_table[i]); + char *entry_pt_name = alloca (strlen (desc_name) + 2); + int j; + + entry_pt_name[0] = '.'; + strcpy (entry_pt_name + 1, desc_name); + + for (j = 0; j < symbol_table_len; j++) + if ((strcmp (bfd_asymbol_name (symbol_table[j]), entry_pt_name) + == 0) + && symbol_table[j]->section->flags & SEC_CODE) + /* Yay! What a coincidence. Let's assume this is the + entry point symbol. */ + { + CORE_ADDR entry_point = bfd_asymbol_value (symbol_table[j]); + do_cleanups (back_to); + return entry_point; + } + + /* No good --- there's no symbol by that name. Perhaps + symbol_table[i] is just coincidentally equal to the + start address; after all, there could be many symbols + with the same value. Continue the search. */ + } + + /* No good --- there's no symbol pointing at the start + address. */ + do_cleanups (back_to); + } + + /* No good --- this BFD has no symbols at all. We give up! */ + return 0; + } + + enum { ELF_NGREG = 48, ELF_NFPREG = 33, *************** *** 1068,1073 **** --- 1168,1175 ---- (gdbarch, ppc64_linux_convert_from_func_ptr_addr); set_gdbarch_call_dummy_address (gdbarch, ppc64_call_dummy_address); + + set_gdbarch_bfd_entry_point (gdbarch, ppc64_linux_bfd_entry_point); set_gdbarch_in_solib_call_trampoline (gdbarch, ppc64_in_solib_call_trampoline);