From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27021 invoked by alias); 2 Dec 2003 15:14:51 -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 27012 invoked from network); 2 Dec 2003 15:14:51 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Dec 2003 15:14:51 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ARCEj-0005Vp-Ix; Tue, 02 Dec 2003 10:14:49 -0500 Date: Tue, 02 Dec 2003 15:14:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Richard Henderson , gdb-patches@sources.redhat.com Subject: Re: [RFA] OSF/1 - "next" over prologueless function call Message-ID: <20031202151449.GA21153@nevyn.them.org> Mail-Followup-To: Joel Brobecker , Richard Henderson , gdb-patches@sources.redhat.com References: <20031202042646.GW1186@gnat.com> <20031202063532.GC31561@redhat.com> <20031202072113.GS22119@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202072113.GS22119@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00048.txt.bz2 On Mon, Dec 01, 2003 at 11:21:13PM -0800, Joel Brobecker wrote: > > Is there any chance we could get hold of the symbol associated with > > this function start? > > I don't know. I think that information is lost after we've read > in the symbol table. However... > > > On ELF detecting this condition can be > > streamlined to > > > > sym->st_other & STO_ALPHA_STD_GPLOAD == STO_ALPHA_STD_GPLOAD > > > > or from bfd, elf_link_hash_entry.other, though I don't remember off > > the top of my head how to get at the elf hash entry from asymbol. > > ... I see some target-specific code uses a grab-bag field of the > minimal_symbol structure to store some target-specific information > (field "info"). I don't particularly fancy typeless fields like this, > but, just thinking aloud, we could add a new fields holding some flags > which would be defined in gdb in an manor independent of the target. > > Also: OSF/1 uses ECOFF. Fortunately, the information seems to be there > too. If you look at a Procedure Descritptor Table Entry, one finds > that it has 2 fields named: "gp_prologue" (byte size of the gp > prologue), and "gp_used" (flag set if the procedure uses gp). I am > not completely clear about the exact significance of the first field, > but it's a promising start. Is this descriptor easily accessible? I imagine that gp_prologue is the byte offset into the function at which you'd jump if you're bypassing the GP load. So it becomes pc == func_start || ECOFF and pc == func_start + gp_prologue || ELF and something similar. Avoiding parsing the code would make me a lot happier. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer