From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26321 invoked by alias); 13 May 2006 14:32:02 -0000 Received: (qmail 25242 invoked by uid 22791); 13 May 2006 14:31:58 -0000 X-Spam-Check-By: sourceware.org Received: from omta05sl.mx.bigpond.com (HELO omta05sl.mx.bigpond.com) (144.140.93.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 May 2006 14:31:44 +0000 Received: from grove.modra.org ([144.136.172.108]) by omta05sl.mx.bigpond.com with ESMTP id <20060513143141.QEOT25409.omta05sl.mx.bigpond.com@grove.modra.org> for ; Sat, 13 May 2006 14:31:41 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id 365711E1FA5; Sun, 14 May 2006 00:01:41 +0930 (CST) Date: Sat, 13 May 2006 14:58:00 -0000 From: Alan Modra To: PAUL GILLIAM , gdb-patches@sources.redhat.com Subject: Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs Message-ID: <20060513143141.GB19700@bubble.grove.modra.org> References: <1147469935.3672.114.camel@dufur.beaverton.ibm.com> <20060512225044.GA20706@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060512225044.GA20706@nevyn.them.org> User-Agent: Mutt/1.4i 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/msg00292.txt.bz2 On Fri, May 12, 2006 at 06:50:44PM -0400, Daniel Jacobowitz wrote: > Hey, Alan, Paul's pointed out that there are no synthetic symbols for > the stubs in -msecure-plt mode. How hard would that be to fix? Not too hard, but messy. The only real difficulty is finding the stubs. We don't have any handy symbols or relocs to identify them, so that means code reading. We do have --emit-stub-syms to emit symbols on stubs at link time. I probably should have made the linker always emit the first stub sym so we could easily find all the stubs. > > > What do you mean by "unknown section"? > > > > This is what I mean: > > (top-gdb) p *bfd_section > > $2 = {name = 0x1049c528 "*UND*", id = 1, index = 0, ... > > That's not an "unknown" section. That's the undefined section! It > means that the symbol has a value, but is marked as undefined. This > is typical for PLT entry stubs, but it's an implementation choice; > I don't think the gABI has much to say about undefined symbols with > addresses. PLT symbols like this, ie. undefined but with nonzero value are a clue to the dynamic linker that it needs to treat the sym specially, to make function pointer comparisons work between an app and its shared libs. > The right thing to do then is probably to create the synthetic symbols > at exactly those same addresses. No, if I understand correctly, Paul wants to use a stub symbol as a means of letting gdb know that it is in a plt call trampoline. Putting the symbol in .plt won't do that for you. Best just teach gdb what a plt call stub looks like. -- Alan Modra IBM OzLabs - Linux Technology Centre