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

Daniel Jacobowitz
2003-12-02T15:14:51Z

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