From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31618 invoked by alias); 15 May 2006 15:09:03 -0000 Received: (qmail 31601 invoked by uid 22791); 15 May 2006 15:09:01 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 15 May 2006 15:08:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ffego-0007Vb-G5; Mon, 15 May 2006 11:08:54 -0400 Date: Mon, 15 May 2006 15:10:00 -0000 From: Daniel Jacobowitz To: Alan Modra Cc: PAUL GILLIAM , gdb-patches@sources.redhat.com Subject: Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs Message-ID: <20060515150854.GA28766@nevyn.them.org> Mail-Followup-To: Alan Modra , PAUL GILLIAM , gdb-patches@sources.redhat.com References: <1147469935.3672.114.camel@dufur.beaverton.ibm.com> <20060512225044.GA20706@nevyn.them.org> <20060513143141.GB19700@bubble.grove.modra.org> <20060513145829.GA3721@nevyn.them.org> <20060515005619.GC19700@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060515005619.GC19700@bubble.grove.modra.org> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00327.txt.bz2 On Mon, May 15, 2006 at 10:26:19AM +0930, Alan Modra wrote: > In thinking about this some more, I remembered why I didn't implement > synthetic stub syms for powerpc. There is a really difficult problem > with -fPIC code, which can have multiple GOTs. The stubs for -fPIC > -shared or -fPIC -pie code calculate the plt entry from the got pointer > used by the calling function. That means we might need multiple stubs > for any given plt entry. eg. printf called from f1 and f2 where f1 uses > a different GOT to f2 will require two stubs and one .plt entry. So we > can't just start from the first stub and match one for one with plt > entries. Worse, code reading the stub doesn't give us a clue about the > got pointer value. So BFD can't match stubs to plt entries without > finding where the stub is falled *from*, and then analysing the function > prologue. This is way too hard. Can't we somehow record them in the object file, then? If they aren't in their own section, we'd have to check for them any time we were stopped without a symbol in .text. And GDB doesn't even know how to use the sizes of symbols, so it may sometimes decide they're part of an earlier function. > > There's two things necessary to make stepping and shared libraries play > > nice. > > > > 1. Be able to unwind from the stub, so that we can see we've stepped > > into something. We need symbols or some other similar code reading in > > order to make this work. > > > > 2. Be able to identify this debug-info-less block of code as a stub, > > so that we can skip it if we're going to step into a shared library > > function that has debug info. I pointed Paul at the right function for > > handling this earlier, but it's somewhat orthogonal. > > I think code reading is the way to go on both of these. Presumably gdb > knows the register state for both of these problems, so finding the > caller (from lr) isn't hard, and you reach the callee just by > single-stepping a few insns. I suppose it could be made to work. It's going to be a bit nasty, though. -- Daniel Jacobowitz CodeSourcery