From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6612 invoked by alias); 27 Jun 2003 18:46:05 -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 6604 invoked from network); 27 Jun 2003 18:46:05 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.2) by sources.redhat.com with SMTP; 27 Jun 2003 18:46:05 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DB6DF2B5F; Fri, 27 Jun 2003 14:46:04 -0400 (EDT) Message-ID: <3EFC90EC.9040502@redhat.com> Date: Fri, 27 Jun 2003 18:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [ppc64-linux] gdbarch hook to find true execution entry point References: <1030611231105.ZM27287@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00825.txt.bz2 >> > --- 1022,1029 ---- >> > the current pc (which should point at the entry point for the >> > dynamic linker) and subtracting the offset of the entry point. */ >> > if (!load_addr_found) >> > ! load_addr = (read_pc () >> > ! - generic_bfd_entry_point (current_gdbarch, tmp_bfd)); >> > >> > /* Record the relocated start and end address of the dynamic linker >> > text and plt section for svr4_in_dynsym_resolve_code. */ > >> >> Shouldn't enable_break() in solib-svr4.c be calling >> gdbarch_bfd_entry_point()? > > > Actually, the overhead of the indirect function call would be a > serious performance problem here. And since using any target other > than PPC64 indicates major pilot error to begin with, I think it's > better that we catch that problem early by having GDB fail at this > point than just paper over the problem by allowing other targets to > function properly. Allowing GDB to run "correctly" on those systems > only creates the illusion that they are adequate for real work. Um, I don't understand this paragraph at all. Which `indirect function call would be a serious performance problem here'? > (Um, yes, thanks for catching that.) > > >> What cases do you know of where calling bfd_get_start_address() is >> insufficient for finding the start address? I'm wondering if we >> need a gdbarch hook at all... > > > The comment on the gdbarch.sh entry is supposed to explain why it's > necessary. I've expanded it a bit; is it clearer? Is there someplace > else I should put it? > > + # The actual instruction address at which ABFD would begin execution. > + # If ABFD is position-independent code, this address is not relocated; > + # it's the address at which execution would begin if the file were > + # loaded at its sections' vmas. > + # > + # On most architectures, this is simply bfd_get_start_address. But on > + # some (like 64-bit PPC), that points to a function descriptor, not an > + # instruction. The descriptor contains the actual entry point, and > + # other pointers needed to call the function. > + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0 So, given a function descriptor at VMA bfd_get_start_address(), there are two possible code addresses: - The relocated address found by reading the descriptor from the target. This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)? - The un-relocated address found by reading the descriptor from the bfd. This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd memory)? and the two values are different. Hence the new method. Several things I'm still missing though: - Is entry_point_address wrong? "symfile.c" sets it to bfd_get_start_address() so (ignoring ppc64 linux), and given an dynamic executable, won't it too need relocating? - Does svr4_relocate_main_executable need to be changed? It is playing with: interp_sect = bfd_get_section_by_name (exec_bfd, ".interp"); if (interp_sect == NULL && (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0 && bfd_get_start_address (exec_bfd) != pc) and then: displacement = pc - bfd_get_start_address (exec_bfd); and my understanding of the above suggests that it too needs changing. Hmm, interp_sect is probably non-NULL so the test would fail, but for consistency? - Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on CALL_DUMMY_ADDRESS, or better, have entry_point_address do this? It would help eliminate CALL_DUMMY_ADDRESS. Andrew