Re: [RFA] OSF/1 - "next" over prologueless function call

[Daniel Jacobowitz <drow@mvista.com>]

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