From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3507 invoked by alias); 30 Jun 2003 22:52:14 -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 3485 invoked from network); 30 Jun 2003 22:52:14 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 30 Jun 2003 22:52:14 -0000 Received: by zenia.home (Postfix, from userid 5433) id 4DA88202BC; Mon, 30 Jun 2003 17:51:44 -0500 (EST) To: Andrew Cagney 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> <3EFC90EC.9040502@redhat.com> From: Jim Blandy Date: Mon, 30 Jun 2003 22:52:00 -0000 In-Reply-To: <3EFC90EC.9040502@redhat.com> 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/msg00884.txt.bz2 Andrew Cagney writes: > > + # 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. That's the important difference, yes. The trick the solib code uses to find the dynamic linker's load offset really does need the unrelocated address --- the amount by which it would need to be relocated is exactly what we're computing there. > 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? Yes, it will need relocation. Executables always used to load at fixed addresses; now they're becoming relocatable to make buffer-overflow attacks harder. So this is a new issue. > - 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? Yes, that should call gdbarch_bfd_entry_point too --- thanks for catching that. > - 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. I'm not sure I understand enough of the details to say anything about this. Why isn't infcall.c just using entry_point_address right now?