From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32165 invoked by alias); 12 May 2006 00:19:19 -0000 Received: (qmail 32156 invoked by uid 22791); 12 May 2006 00:19:18 -0000 X-Spam-Check-By: sourceware.org Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 00:19:14 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4C0JBow005291 for ; Thu, 11 May 2006 20:19:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4C0J7rX120846 for ; Thu, 11 May 2006 18:19:10 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k4C0J75p017383 for ; Thu, 11 May 2006 18:19:07 -0600 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k4C0J7xS017340 for ; Thu, 11 May 2006 18:19:07 -0600 Subject: Re: Strange stepping behaviour with PPC 32 and secure PLTs From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: gdb@sources.redhat.com In-Reply-To: <1143758781.21920.464.camel@dufur.beaverton.ibm.com> References: <1143758781.21920.464.camel@dufur.beaverton.ibm.com> Content-Type: text/plain Date: Fri, 12 May 2006 05:49:00 -0000 Message-Id: <1147389317.3672.46.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00156.txt.bz2 This is a followup to this message: http://sourceware.org/ml/gdb/2006-03/msg00224.html To recap, when I try to 'next' over a call to a library subroutine, it kind of does a stepi instead. This is for a 32-bit ppc target program that uses the new secure PLT's. After some digging, I have found that the code in infrun.c that is supposed to notice that we are next'ing over a subroutine call isn't. Here is an excerpt: if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) { /* It's a subroutine call. */ CORE_ADDR real_stop_pc; . . . if (step_over_calls == STEP_OVER_ALL) { /* We're doing a "next", set a breakpoint at callee's return address (the address at which the caller will resume). */ insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ())); keep_going (ecs); return; } . . . } The reason this code is not working is that the two frame ID's are different: the call to frame_unwind_id is not working because lookup_minimal_symbol_by_pc_section() can't find the right symbol. It does find a symbol that would work, but because the it's in the 'unknown' section and the PC is in the '.text' section, it's ignored. It might be more accurate to say that there is no 'right' symbol. In the non-secure PLT case, there is a symbol 'foo@plt' where foo is the name of the library subroutine. This is a synthetic symbol made up by BFD for the plt associated with 'foo' and it's in the '.plt' secton. Sense PLT's are executable, the PC will also be in the '.plt' section and all is well. In the secure PLT case, the ignored symbol in the 'unknown' section is taken from the executables symbol table. BFD does synthesize a 'foo@plt' symbol, but it's in the '.data' section, as it should be sense secure PLT's are not executable. One way to fix this is for BFD to synthesize a new symbol in addition to 'foo@plt', let's say we call it 'foo@stub'. This new symbol would be in the '.text' section and would be found by lookup_minimal_symbol_by_pc_section() and all would be well. BFD would know that such a symbol should be generated if it was dealing with a ppc32 object file whose '.plt' section was not executable. I would rather have a GDB only solution. A possibility would be to change lookup_minimal_symbol_by_pc_section() so that a symbol in the 'unknown' section would not be ignored if it was of type 'mst_solib_trampoline'. Or we could change prim_record_minimal_symbol_and_info() to set the section to SECT_OFF_TEXT (objfile) if the type is 'mst_solib_trampoline' (this is what prim_record_minimal_symbol() does). /* I tried this and it's not quite what's needed: we need to diddle with 'bfd_section', not 'section'. */ Any thoughts? If I don't hear anything soon, I'll submit a better patch to hack prim_record_minimal_symbol_and_info() to gdb-patches@ and see what happens in that list. -=# Paul #=-