This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA] use frame IDs to detect function calls while stepping


Hello,

This is a followup on the discussion that took place in the following
thread:

    [RFA] OSF/1 - "next" over prologueless function call
    http://sources.redhat.com/ml/gdb-patches/2003-12/msg00037.html

During the discussion, it appeared that it was better to rely on
frame IDs to detect cases when we stepped inside a function rather
than further adjusting the test that checks whether we landed at
the begining of a function or not.

After a bit of testing on various platforms, I found that only relying
on a test that checks the ID of frame #1 against the step_frame_id was
not sufficient, unfortunately. The sparc-solaris testing revealed 2
regressions.

After careful analysis of the regressions and a bit of dicussion
with Andrew, here is what we found:

  1. We sometimes step levels of function calls down from the point
     where we started stepping. This is to get past the dynsym
     resolve code. So once we get more than one level deep, the
     frame ID test can no longer work.
     
     That was regression #1.

  2. We have a testcase where we try to "next" our way out of a function
     for which we have no line number information. The expected output
     was to run until the end of the program. But instead we stopped
     before.

     It turned out that we were landing inside a shared library
     trampoline after having left the function we were in, so again
     the frame ID check didn't kick in. We didn't know what to do,
     simply stopped there.

     That was regression #2.

Given the current implementation, and the analysis of the regressions,
we determined that the logic should be something like this:

  . If we landed in undebuggable code (identified by lack of symbol
    name), and we're stepping over this kind of code, then:
    
        Run our way out of the function.
  
  . If we are in a shlib call trampoline, then:

        Likewise.
        (This test was already part of the previous check, BTW)

  . If we are in a function called from the function where we started
    stepping, as identified by frame ID unwind, then:

        Likewise.

I tried it and no longer had any regression.

2004-02-05  J. Brobecker  <brobecker@gnat.com>

        * infrun.c (handle_inferior_event): Rewrite the checks detecting
        cases when we stepped inside a function.

Tested on alpha-tru64, pa-hpux, sparc-solaris and x86-linux.
And it also fixes the problem I originally reported.

OK to apply?

Thanks,
-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]