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] |
[aghaaaaa .... With the patch this time, with my thanks to Elena and Daniel] 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
Attachment:
infrun.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |