From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9715 invoked by alias); 29 Jul 2003 03:11:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9699 invoked from network); 29 Jul 2003 03:11:07 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 29 Jul 2003 03:11:07 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19hKtH-0000Ha-3u; Mon, 28 Jul 2003 23:11:07 -0400 Date: Tue, 29 Jul 2003 03:11:00 -0000 From: Daniel Jacobowitz To: binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: fake symbols to aid debugging Message-ID: <20030729031107.GA987@nevyn.them.org> Mail-Followup-To: binutils@sources.redhat.com, gdb@sources.redhat.com References: <20030729023258.GH27145@bubble.sa.bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030729023258.GH27145@bubble.sa.bigpond.net.au> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00325.txt.bz2 On Tue, Jul 29, 2003 at 12:02:58PM +0930, Alan Modra wrote: > PowerPC64 (and other architechures) use linker stubs for various things, > most notably to make calls to functions in shared objects. Typical > disassembly looks like: > > the stub > 7ea138: 3d 82 00 01 addis r12,r2,1 > 7ea13c: f8 41 00 28 std r2,40(r1) > 7ea140: e9 6c 11 88 ld r11,4488(r12) > 7ea144: e8 4c 11 90 ld r2,4496(r12) > 7ea148: 7d 69 03 a6 mtctr r11 > 7ea14c: e9 6c 11 98 ld r11,4504(r12) > 7ea150: 4e 80 04 20 bctr > > call to stub > 87d6f0: e8 7e 80 90 ld r3,-32624(r30) > 87d6f4: 4b f6 ca 45 bl 7ea138 <._init+0xe9b8> > 87d6f8: e8 41 00 28 ld r2,40(r1) > > Note the meaningless symbol given as target for the "bl". Now, if you > know enough about the ABI, it's possible to figure out which function is > being called, but that's a pain. In the case of PowerPC64 you need to > a) Find the value of r2 by looking at the calling function's opd entry. > (with multiple GOT/TOC r2 is not fixed). > b) Perform the calculation done by the stub to find the plt entry > address. > c) Search the relocs to find the one for this particular plt entry. > The symbol on the reloc gives the function name. > > I waste enough time doing this that I figure it's worth doing something > about it. My first idea, already implemented, was to have the linker > emit extra symbols to identify the stubs. This works well but bloats > the symbol table and isn't on by default. A better idea would be to > create the stub symbols on the fly. With that in mind, I propose to > add two new bfd functions > > long bfd_get_fake_symtab_upper_bound (bfd *abfd); > long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf); > > analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab. > > Comments? I may regret suggesting this... outgrowth of a similar conversation with Jim a month or so ago. Would it be feasible for the linker to generate a DWARF compilation unit for these stubs, and fill it with DW_AT_trampoline markers? One of the forms of DW_AT_trampoline is just a string which gives the function name, which is all you'd want from what you said above. As link-time DWARF generation goes this is a pretty simple one; you'd only need one form. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer