question on gdbarch_skip_prologue()

question on gdbarch_skip_prologue()

[David Mosberger]

Hello,

I'm exploring the idea of changing the ia64 backend of gdb to use
unwind information instead of code-reading.  While looking into this,
I started to wonder how gdbarch_skip_prologue() should be implemented.
Some backends simply return the PC that was passed into the routine,
i.e., they always assume a zero-size prologue.  I'm tempted to do the
same because I worry that with optimized code, the very notion of a
prologue becomes quite fuzzy.  For example, a prologue might contain a
branch and, if so, there may not even be a single PC that corresponds
to the end of the prologue.

Are there any downsides to gdbarch_skip_prologue() always returning
the original PC?  Since the unwind info is accurate no matter what the
PC is, there are no problems with tracking the contents of preserved
(callee-saved) registers, but I'm wondering whether I'm missing
anything else.

Thanks,

	--david

Re: question on gdbarch_skip_prologue()

[Kevin Buettner]

On Mar 6, 10:28pm, David Mosberger wrote:

> I'm exploring the idea of changing the ia64 backend of gdb to use
> unwind information instead of code-reading.  While looking into this,
> I started to wonder how gdbarch_skip_prologue() should be implemented.
> Some backends simply return the PC that was passed into the routine,
> i.e., they always assume a zero-size prologue.  I'm tempted to do the
> same because I worry that with optimized code, the very notion of a
> prologue becomes quite fuzzy.  For example, a prologue might contain a
> branch and, if so, there may not even be a single PC that corresponds
> to the end of the prologue.
> 
> Are there any downsides to gdbarch_skip_prologue() always returning
> the original PC?  Since the unwind info is accurate no matter what the
> PC is, there are no problems with tracking the contents of preserved
> (callee-saved) registers, but I'm wondering whether I'm missing
> anything else.

GDB currently expects that the skip_prologue() function will return a
PC that's after the last prologue instruction that saved an argument
to its "home" location (if any) in memory (or whereever the debug info
says that a parameter's location is).  The difficulty with this, of
course, is that with optimized code, it can be very difficult to
discern where this is.

Kevin

Re: question on gdbarch_skip_prologue()

[David Mosberger]

>>>>> On Thu, 7 Mar 2002 01:11:17 -0700, Kevin Buettner <kevinb@redhat.com> said:

  Kevin> GDB currently expects that the skip_prologue() function will
  Kevin> return a PC that's after the last prologue instruction that
  Kevin> saved an argument to its "home" location (if any) in memory
  Kevin> (or whereever the debug info says that a parameter's location
  Kevin> is).  The difficulty with this, of course, is that with
  Kevin> optimized code, it can be very difficult to discern where
  Kevin> this is.

So, if I may paraphrase, skip_prologue() returns the PC of the first
instruction for which the debug info will be valid, right?

If so, I'd argue this has much more to do with debug info than with
unwind info.  For example, hand-written assembly routines often have
sizable prologues, but a programmer would almost certainly want a
breakpoint to be placed right at the beginning of the function, not at
the end of the prologue.

Now, I wonder whether it wouldn't be possible and indeed better to
implement skip_prologue() based on debug info.  Unfortunately, I'm not
very familiar with, say, DWARF2.  However, I did notice that applying
the "info line" command to the first line of source code in a C
program does indeed return a starting address that corresponds to the
value that ought to be returned by skip_prologue().

Perhaps skip_prologue() could look for the first PC that is covered by
line info and return that value (or the original PC if there is no
such PC)?  To be on the safe side, skip_prologue() probably ought to
give up the search as soon as it sees a branch instruction.

Would this be a safe algorithm?

	--david

Re: question on gdbarch_skip_prologue()

[Kevin Buettner]

On Mar 7, 10:12am, David Mosberger wrote:

> >>>>> On Thu, 7 Mar 2002 01:11:17 -0700, Kevin Buettner <kevinb@redhat.com> said:
> 
>   Kevin> GDB currently expects that the skip_prologue() function will
>   Kevin> return a PC that's after the last prologue instruction that
>   Kevin> saved an argument to its "home" location (if any) in memory
>   Kevin> (or whereever the debug info says that a parameter's location
>   Kevin> is).  The difficulty with this, of course, is that with
>   Kevin> optimized code, it can be very difficult to discern where
>   Kevin> this is.
> 
> So, if I may paraphrase, skip_prologue() returns the PC of the first
> instruction for which the debug info will be valid, right?

Right.

But you should also know that most (all?) of us working on GDB don't
really like this behavior and are eagerly waiting for the day when
it'll be possible to implement skip_prologue() as the identity
function (on the first argument).

> If so, I'd argue this has much more to do with debug info than with
> unwind info.  For example, hand-written assembly routines often have
> sizable prologues, but a programmer would almost certainly want a
> breakpoint to be placed right at the beginning of the function, not at
> the end of the prologue.

That's true.

> Now, I wonder whether it wouldn't be possible and indeed better to
> implement skip_prologue() based on debug info.  Unfortunately, I'm not
> very familiar with, say, DWARF2.  However, I did notice that applying
> the "info line" command to the first line of source code in a C
> program does indeed return a starting address that corresponds to the
> value that ought to be returned by skip_prologue().

I believe that there are implementations of skip_prologue() which do
exactly that.  You can find a somewhat better algorithm in
refine_prologue_limit() in ia64-tdep.c.  (It works for optimized
prologues too.)

I should note that this method doesn't work well when you have a
function written all on one line like this:

    int sum (int a, int b) { int c = a + b; return c; }

> Perhaps skip_prologue() could look for the first PC that is covered by
> line info and return that value (or the original PC if there is no
> such PC)?  To be on the safe side, skip_prologue() probably ought to
> give up the search as soon as it sees a branch instruction.
> 
> Would this be a safe algorithm?

I think so, though you probably want it to stop at predicated
instructions too.  (Plus you should consider using the
refine_prologue_limit() algorithm.)

Kevin

Re: question on gdbarch_skip_prologue()

[David Mosberger]

>>>>> On Thu, 7 Mar 2002 11:41:28 -0700, Kevin Buettner <kevinb@redhat.com> said:

  Kevin> But you should also know that most (all?) of us working on
  Kevin> GDB don't really like this behavior and are eagerly waiting
  Kevin> for the day when it'll be possible to implement
  Kevin> skip_prologue() as the identity function (on the first
  Kevin> argument).

Ah, I'm happy to hear that.

OK, here is my take then: longer term, skip_prologue() should become
an identity function.  In the interim, we can continue to use
code-reading based heuristics and debug info to implement it.  The
important point for me is that the routine does not need any special
support from the unwind library.

Of course, this implies that, for the moment, we can't get rid of
code-reading entirely in gdb/ia64, but longer term, we will be able to
do so.

	--david