* [RFC] - Exposing find_pc_line through Python API
@ 2012-05-07 18:11 Siva Chandra
2012-05-07 19:36 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Siva Chandra @ 2012-05-07 18:11 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
Hi all,
I wanted a way to get the actual line number given a PC value using
the Python API. The currently available Symtab_and_line.line gives
the line number which the user thinks the current execution is, but
not the actual. Attached is a patch which adds gdb.find_pc_line
corresponding to the C function find_pc_line.
2012-05-07 Siva Chandra Reddy <sivachandra@google.com>
Add a new function gdb.find_pc_line to the Python API.
* python/python.c (gdbpy_find_pc_line): New function which
implements gdb.find_pc_line.
doc/
* gdb.texinfo (Basic Python): Add description about the function
gdb.find_pc_line
testsuite/
* gdb.python/python.c: Add a new breakpoint location.
* gdb.python/python.exp: Add tests to test gdb.find_pc_line.
Thanks,
Siva Chandra
[-- Attachment #2: pc_line_patch_v1.txt --]
[-- Type: text/plain, Size: 5780 bytes --]
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.955
diff -u -p -r1.955 gdb.texinfo
--- doc/gdb.texinfo 6 May 2012 15:31:04 -0000 1.955
+++ doc/gdb.texinfo 7 May 2012 17:55:53 -0000
@@ -22392,6 +22392,53 @@ compute values, for example, it is the o
convenience variable (@pxref{Convenience Vars}) as a @code{gdb.Value}.
@end defun
+@findex gdb.find_pc_line
+@defun gdb.find_pc_line (pc [, actual])
+Return the @code{gdb.Symtab_and_line} object corresponding to the
+@var{pc} value. If @var{actual} is @code{True}, it returns the
+@code{gdb.Symtab_and_line} object with the actual line corresponding
+to the pc value. Otherwise, it returns the @code{gdb.Symtab_and_line}
+object with a line which the user feels the execution is currently at.
+If @var{actual} is not specified, it defaults to @code{True}.
+@xref{Symbol Tables In Python}
+
+The difference between @var{actual} being @code{True} or @code{False}
+can be illustrated with an example. Let a call to a function @code{func}
+be on line 20 in a C source file as
+
+@smallexample
+18 ...
+19
+20 func ();
+21
+22 return 0;
+23
+24 ...
+@end smallexample
+
+After executing @value{GDBN} commands @code{step} followed by @code{up}
+at line 20, the actual value of the @code{PC} register should correspond
+to the next code line at line 22. However, since the function
+@code{func} has not yet been executed, the user feels that the execution
+is still at line 20 (the call site) in the caller. Hence, invoking
+
+@smallexample
+gdb.find_pc_line (gdb.selected_frame().pc(), True)
+@end smallexample
+
+@noindent
+will return a @code{gdb.Symtab_and_line} object corresponding to the
+actual line 22, while invoking
+
+@smallexample
+gdb.find_pc_line (gdb.selected_frame().pc(), False)
+@end smallexample
+
+@noindent
+will return a @code{gdb.Symtab_and_line} object corresponding to the
+call site line 20.
+@end defun
+
@findex gdb.post_event
@defun gdb.post_event (event)
Put @var{event}, a callable object taking no arguments, into
Index: python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/python/python.c,v
retrieving revision 1.86
diff -u -p -r1.86 python.c
--- python/python.c 30 Mar 2012 20:05:55 -0000 1.86
+++ python/python.c 7 May 2012 17:55:54 -0000
@@ -631,6 +631,28 @@ gdbpy_parse_and_eval (PyObject *self, Py
return value_to_value_object (result);
}
+/* Implementation of gdb.find_pc_line function.
+ Returns the gdb.Symtab_and_line object corresponding to a PC value. */
+
+static PyObject *
+gdbpy_find_pc_line (PyObject *self, PyObject *args)
+{
+ struct symtab_and_line sal;
+ CORE_ADDR pc;
+ PyObject *actual = NULL;
+ int notcurrent = 0;
+
+ if (!PyArg_ParseTuple (args, (GDB_PY_LLU_ARG "|O!"), &pc, &PyBool_Type,
+ &actual))
+ return NULL;
+
+ if (actual)
+ notcurrent = !PyObject_IsTrue (actual);
+
+ sal = find_pc_line (pc, notcurrent);
+ return symtab_and_line_to_sal_object (sal);
+}
+
/* Read a file as Python code.
FILE is the file to run. FILENAME is name of the file FILE.
This does not throw any errors. If an exception occurs python will print
@@ -1458,6 +1480,14 @@ gdb.Symtab_and_line objects (or None)."}
"parse_and_eval (String) -> Value.\n\
Parse String as an expression, evaluate it, and return the result as a Value."
},
+ { "find_pc_line", gdbpy_find_pc_line, METH_VARARGS,
+ "find_pc_line (pc[, actual]) -> Symtab_and_line.\n\
+Return the gdb.Symtab_and_line object corresponding to the pc value. If\n\
+actual is True, it returns the gdb.Symtab_and_line object with the actual\n\
+line corresponding to the pc value. Otherwise, it returns the\n\
+gdb.Symtab_and_line object with a line which the users feels the execution\n\
+is currently at. If actual is not specified, it defaults to True."
+ },
{ "post_event", gdbpy_post_event, METH_VARARGS,
"Post an event into gdb's event loop." },
Index: testsuite/gdb.python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.c,v
retrieving revision 1.4
diff -u -p -r1.4 python.c
--- testsuite/gdb.python/python.c 4 Jan 2012 08:27:49 -0000 1.4
+++ testsuite/gdb.python/python.c 7 May 2012 17:55:59 -0000
@@ -23,6 +23,6 @@ int
main (int argc, char *argv[])
{
func1 ();
- func2 ();
+ func2 (); /* Break at func2 call site. */
return 0; /* Break to end. */
}
Index: testsuite/gdb.python/python.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.exp,v
retrieving revision 1.32
diff -u -p -r1.32 python.exp
--- testsuite/gdb.python/python.exp 30 Mar 2012 19:16:52 -0000 1.32
+++ testsuite/gdb.python/python.exp 7 May 2012 17:55:59 -0000
@@ -367,3 +367,23 @@ gdb_test_multiple "python gdb.prompt_hoo
gdb_py_test_silent_cmd "python gdb.prompt_hook = None" \
"set the hook to default" 1
+
+# Start with a fresh gdb.
+clean_restart ${testfile}
+
+# The following tests require execution.
+
+if ![runto_main] then {
+ fail "Can't run to main"
+ return 0
+}
+
+runto [gdb_get_line_number "Break at func2 call site."]
+
+gdb_py_test_silent_cmd "step" "Step into func2" 1
+gdb_py_test_silent_cmd "up" "Step out of func2" 1
+gdb_py_test_silent_cmd "python line = gdb.selected_frame().find_sal().line" "Get line number of func2 call site" 1
+
+# Test gdb.find_pc_line
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc(), True).line > line" "True" "Get actual line"
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc(), False).line == line" "True" "Get user line"
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-07 18:11 [RFC] - Exposing find_pc_line through Python API Siva Chandra
@ 2012-05-07 19:36 ` Eli Zaretskii
2012-05-08 2:35 ` Siva Chandra
2012-05-09 7:35 ` Siva Chandra
0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2012-05-07 19:36 UTC (permalink / raw)
To: Siva Chandra; +Cc: gdb-patches
> Date: Mon, 7 May 2012 23:41:25 +0530
> From: Siva Chandra <sivachandra@google.com>
>
> I wanted a way to get the actual line number given a PC value using
> the Python API. The currently available Symtab_and_line.line gives
> the line number which the user thinks the current execution is, but
> not the actual.
That "user thinks the execution is at" notion is far from being
clear to me. See below.
> Attached is a patch which adds gdb.find_pc_line corresponding to the
> C function find_pc_line.
Thanks.
> +@defun gdb.find_pc_line (pc [, actual])
> +Return the @code{gdb.Symtab_and_line} object corresponding to the
> +@var{pc} value. If @var{actual} is @code{True}, it returns the
^^^^^^^^^^
"return", for consistency with the first sentence.
> +@code{gdb.Symtab_and_line} object with the actual line corresponding
> +to the pc value. Otherwise, it returns the @code{gdb.Symtab_and_line}
^^^^^^^^^^
Likewise.
> +The difference between @var{actual} being @code{True} or @code{False}
> +can be illustrated with an example. Let a call to a function @code{func}
> +be on line 20 in a C source file as
> +
> +@smallexample
> +18 ...
> +19
> +20 func ();
> +21
> +22 return 0;
> +23
> +24 ...
> +@end smallexample
> +
> +After executing @value{GDBN} commands @code{step} followed by @code{up}
> +at line 20, the actual value of the @code{PC} register should correspond
> +to the next code line at line 22. However, since the function
> +@code{func} has not yet been executed, the user feels that the execution
> +is still at line 20 (the call site) in the caller.
If I were that user, I would "feel" that the execution is at the first
line (or maybe in the prologue) of 'func', since PC is (in my mind)
unaffected by commands that walk the call stack. And if you are
talking about the value of PC saved in the frame of the caller of
'func', then saying that line 22 is the "actual" location is again
confusing, because execution did not yet reach that point.
So I have hard time understanding why we need the distinction. And
since you say that the current Symtab_and_line.line gives the second
alternatives, I'm confused even more.
It's possible that I'm the only confused person here, but in that
case, at least the example should be fixed to show and explain the
distinction more clearly and unequivocally, and also in which
situations the "actual" value is useful.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-07 19:36 ` Eli Zaretskii
@ 2012-05-08 2:35 ` Siva Chandra
2012-05-09 7:35 ` Siva Chandra
1 sibling, 0 replies; 9+ messages in thread
From: Siva Chandra @ 2012-05-08 2:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
Siva> +The difference between @var{actual} being @code{True} or @code{False}
Siva> +can be illustrated with an example. Let a call to a function @code{func}
Siva> +be on line 20 in a C source file as
Siva> +
Siva> +@smallexample
Siva> +18 ...
Siva> +19
Siva> +20 func ();
Siva> +21
Siva> +22 return 0;
Siva> +23
Siva> +24 ...
Siva> +@end smallexample
Siva> +
Siva> +After executing @value{GDBN} commands @code{step} followed by @code{up}
Siva> +at line 20, the actual value of the @code{PC} register should correspond
Siva> +to the next code line at line 22. However, since the function
Siva> +@code{func} has not yet been executed, the user feels that the execution
Siva> +is still at line 20 (the call site) in the caller.
Eli> If I were that user, I would "feel" that the execution is at the first
Eli> line (or maybe in the prologue) of 'func', since PC is (in my mind)
Eli> unaffected by commands that walk the call stack. And if you are
Eli> talking about the value of PC saved in the frame of the caller of
Eli> 'func', then saying that line 22 is the "actual" location is again
Eli> confusing, because execution did not yet reach that point.
Not just the PC saved in the frame of the caller of 'func', even $pc
will have the same value. If after a 'step' and 'up' you do 'print /d
$pc', it will print the same value as
(gdb) python print gdb.selected_frame().pc()
Eli> So I have hard time understanding why we need the distinction. And
Eli> since you say that the current Symtab_and_line.line gives the second
Eli> alternatives, I'm confused even more.
I do not understand myself why the second alternative was selected to
reflect in Symtab_and_line.line.
Eli> It's possible that I'm the only confused person here, but in that
Eli> case, at least the example should be fixed to show and explain the
Eli> distinction more clearly and unequivocally, and also in which
Eli> situations the "actual" value is useful.
I am working on something for which I need to know the last function
call on a particular source line. The heuristic I am trying to use is
that, when we 'step' in and out (via 'up') of the last function call,
the PC should correspond to the next source line and not the call site
of the last function call.
Thanks,
Siva Chandra
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-07 19:36 ` Eli Zaretskii
2012-05-08 2:35 ` Siva Chandra
@ 2012-05-09 7:35 ` Siva Chandra
2012-05-09 20:05 ` Eli Zaretskii
2012-05-10 21:16 ` Doug Evans
1 sibling, 2 replies; 9+ messages in thread
From: Siva Chandra @ 2012-05-09 7:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
Eli> If I were that user, I would "feel" that the execution is at the first
Eli> line (or maybe in the prologue) of 'func', since PC is (in my mind)
Eli> unaffected by commands that walk the call stack. And if you are
Eli> talking about the value of PC saved in the frame of the caller of
Eli> 'func', then saying that line 22 is the "actual" location is again
Eli> confusing, because execution did not yet reach that point.
Eli> So I have hard time understanding why we need the distinction. And
Eli> since you say that the current Symtab_and_line.line gives the second
Eli> alternatives, I'm confused even more.
Eli> It's possible that I'm the only confused person here, but in that
Eli> case, at least the example should be fixed to show and explain the
Eli> distinction more clearly and unequivocally, and also in which
Eli> situations the "actual" value is useful.
The more I think about your comments, the more I feel that exposing
this 'actual' argument is not a good idea. I am now of the opinion
that the 'notcurrent' argument to the internal function find_pc_line
caters to a internal usage which depends on much more than just what
the user feels. Hence, I have modified the patch to remove the
'actual' argument. The new version of the patch is attached.
2012-05-07 Siva Chandra Reddy <sivachandra@google.com>
Add a new function gdb.find_pc_line to the Python API.
* NEWS (Python Scripting): Add entry about the new function.
* python/python.c (gdbpy_find_pc_line): New function which
implements gdb.find_pc_line.
(GdbMethods): Add entry for the new function.
doc/
* gdb.texinfo (Basic Python): Add description about the function
gdb.find_pc_line
testsuite/
* gdb.python/python.c: Add a new breakpoint comment.
* gdb.python/python.exp: Add tests to test gdb.find_pc_line.
Thanks,
Siva Chandra
[-- Attachment #2: pc_line_patch_v2.txt --]
[-- Type: text/plain, Size: 4624 bytes --]
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.514
diff -u -p -r1.514 NEWS
--- NEWS 3 May 2012 07:07:24 -0000 1.514
+++ NEWS 9 May 2012 06:23:26 -0000
@@ -43,6 +43,9 @@
which return the global and static blocks (as gdb.Block objects),
of the underlying symbol table, respectively.
+ ** New function gdb.find_pc_line which returns the gdb.Symtab_and_line
+ object associated with a PC value.
+
* Go language support.
GDB now supports debugging programs written in the Go programming
language.
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.955
diff -u -p -r1.955 gdb.texinfo
--- doc/gdb.texinfo 6 May 2012 15:31:04 -0000 1.955
+++ doc/gdb.texinfo 9 May 2012 06:23:32 -0000
@@ -22392,6 +22392,12 @@ compute values, for example, it is the o
convenience variable (@pxref{Convenience Vars}) as a @code{gdb.Value}.
@end defun
+@findex gdb.find_pc_line
+@defun gdb.find_pc_line (pc)
+Return the @code{gdb.Symtab_and_line} object corresponding to the
+@var{pc} value. @xref{Symbol Tables In Python}.
+@end defun
+
@findex gdb.post_event
@defun gdb.post_event (event)
Put @var{event}, a callable object taking no arguments, into
Index: python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/python/python.c,v
retrieving revision 1.86
diff -u -p -r1.86 python.c
--- python/python.c 30 Mar 2012 20:05:55 -0000 1.86
+++ python/python.c 9 May 2012 06:23:32 -0000
@@ -631,6 +631,25 @@ gdbpy_parse_and_eval (PyObject *self, Py
return value_to_value_object (result);
}
+/* Implementation of gdb.find_pc_line function.
+ Returns the gdb.Symtab_and_line object corresponding to a PC value. */
+
+static PyObject *
+gdbpy_find_pc_line (PyObject *self, PyObject *args)
+{
+ struct symtab_and_line sal;
+ CORE_ADDR pc;
+ unsigned long long pc_llu;
+ PyObject *actual = NULL;
+
+ if (!PyArg_ParseTuple (args, GDB_PY_LLU_ARG, &pc_llu))
+ return NULL;
+
+ pc = (CORE_ADDR) pc_llu;
+ sal = find_pc_line (pc, 0);
+ return symtab_and_line_to_sal_object (sal);
+}
+
/* Read a file as Python code.
FILE is the file to run. FILENAME is name of the file FILE.
This does not throw any errors. If an exception occurs python will print
@@ -1458,6 +1477,9 @@ gdb.Symtab_and_line objects (or None)."}
"parse_and_eval (String) -> Value.\n\
Parse String as an expression, evaluate it, and return the result as a Value."
},
+ { "find_pc_line", gdbpy_find_pc_line, METH_VARARGS,
+ "find_pc_line (pc) -> Symtab_and_line.\n\
+Return the gdb.Symtab_and_line object corresponding to the pc value." },
{ "post_event", gdbpy_post_event, METH_VARARGS,
"Post an event into gdb's event loop." },
Index: testsuite/gdb.python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.c,v
retrieving revision 1.4
diff -u -p -r1.4 python.c
--- testsuite/gdb.python/python.c 4 Jan 2012 08:27:49 -0000 1.4
+++ testsuite/gdb.python/python.c 9 May 2012 06:23:32 -0000
@@ -23,6 +23,6 @@ int
main (int argc, char *argv[])
{
func1 ();
- func2 ();
+ func2 (); /* Break at func2 call site. */
return 0; /* Break to end. */
}
Index: testsuite/gdb.python/python.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.exp,v
retrieving revision 1.32
diff -u -p -r1.32 python.exp
--- testsuite/gdb.python/python.exp 30 Mar 2012 19:16:52 -0000 1.32
+++ testsuite/gdb.python/python.exp 9 May 2012 06:23:32 -0000
@@ -367,3 +367,23 @@ gdb_test_multiple "python gdb.prompt_hoo
gdb_py_test_silent_cmd "python gdb.prompt_hook = None" \
"set the hook to default" 1
+
+# Start with a fresh gdb.
+clean_restart ${testfile}
+
+# The following tests require execution.
+
+if ![runto_main] then {
+ fail "Can't run to main"
+ return 0
+}
+
+runto [gdb_get_line_number "Break at func2 call site."]
+
+gdb_py_test_silent_cmd "python line = gdb.selected_frame().find_sal().line" "Get line number of func2 call site" 1
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc()).line == line" "True" "Test find_pc_line at func2 call site"
+
+gdb_py_test_silent_cmd "step" "Step into func2" 1
+gdb_py_test_silent_cmd "up" "Step out of func2" 1
+
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc()).line > line" "True" "Test find_pc_line with resume address"
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-09 7:35 ` Siva Chandra
@ 2012-05-09 20:05 ` Eli Zaretskii
2012-05-10 21:16 ` Doug Evans
1 sibling, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2012-05-09 20:05 UTC (permalink / raw)
To: Siva Chandra; +Cc: gdb-patches
> Date: Wed, 9 May 2012 13:05:01 +0530
> From: Siva Chandra <sivachandra@google.com>
> Cc: gdb-patches@sourceware.org
>
>
> [1:text/plain Hide]
>
> Eli> If I were that user, I would "feel" that the execution is at the first
> Eli> line (or maybe in the prologue) of 'func', since PC is (in my mind)
> Eli> unaffected by commands that walk the call stack. Â And if you are
> Eli> talking about the value of PC saved in the frame of the caller of
> Eli> 'func', then saying that line 22 is the "actual" location is again
> Eli> confusing, because execution did not yet reach that point.
>
> Eli> So I have hard time understanding why we need the distinction. Â And
> Eli> since you say that the current Symtab_and_line.line gives the second
> Eli> alternatives, I'm confused even more.
>
> Eli> It's possible that I'm the only confused person here, but in that
> Eli> case, at least the example should be fixed to show and explain the
> Eli> distinction more clearly and unequivocally, and also in which
> Eli> situations the "actual" value is useful.
>
> The more I think about your comments, the more I feel that exposing
> this 'actual' argument is not a good idea. I am now of the opinion
> that the 'notcurrent' argument to the internal function find_pc_line
> caters to a internal usage which depends on much more than just what
> the user feels. Hence, I have modified the patch to remove the
> 'actual' argument. The new version of the patch is attached.
>
> 2012-05-07 Siva Chandra Reddy <sivachandra@google.com>
>
> Add a new function gdb.find_pc_line to the Python API.
> * NEWS (Python Scripting): Add entry about the new function.
> * python/python.c (gdbpy_find_pc_line): New function which
> implements gdb.find_pc_line.
> (GdbMethods): Add entry for the new function.
>
> doc/
> * gdb.texinfo (Basic Python): Add description about the function
> gdb.find_pc_line
OK for these two parts.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-09 7:35 ` Siva Chandra
2012-05-09 20:05 ` Eli Zaretskii
@ 2012-05-10 21:16 ` Doug Evans
2012-05-11 16:35 ` Siva Chandra
1 sibling, 1 reply; 9+ messages in thread
From: Doug Evans @ 2012-05-10 21:16 UTC (permalink / raw)
To: Siva Chandra; +Cc: Eli Zaretskii, gdb-patches
On Wed, May 9, 2012 at 12:35 AM, Siva Chandra <sivachandra@google.com> wrote:
> The more I think about your comments, the more I feel that exposing
> this 'actual' argument is not a good idea. I am now of the opinion
> that the 'notcurrent' argument to the internal function find_pc_line
> caters to a internal usage which depends on much more than just what
> the user feels. Hence, I have modified the patch to remove the
> 'actual' argument. The new version of the patch is attached.
>
> 2012-05-07 Siva Chandra Reddy <sivachandra@google.com>
>
> Add a new function gdb.find_pc_line to the Python API.
> * NEWS (Python Scripting): Add entry about the new function.
> * python/python.c (gdbpy_find_pc_line): New function which
> implements gdb.find_pc_line.
> (GdbMethods): Add entry for the new function.
>
> doc/
> * gdb.texinfo (Basic Python): Add description about the function
> gdb.find_pc_line
>
> testsuite/
> * gdb.python/python.c: Add a new breakpoint comment.
> * gdb.python/python.exp: Add tests to test gdb.find_pc_line.
+@findex gdb.find_pc_line
+@defun gdb.find_pc_line (pc)
+Return the @code{gdb.Symtab_and_line} object corresponding to the
+@var{pc} value. @xref{Symbol Tables In Python}.
+@end defun
I think we need to specify what the result is if there is no sal for
the specified pc.
+/* Implementation of gdb.find_pc_line function.
+ Returns the gdb.Symtab_and_line object corresponding to a PC value. */
+
+static PyObject *
+gdbpy_find_pc_line (PyObject *self, PyObject *args)
+{
+ struct symtab_and_line sal;
+ CORE_ADDR pc;
+ unsigned long long pc_llu;
+ PyObject *actual = NULL;
+
+ if (!PyArg_ParseTuple (args, GDB_PY_LLU_ARG, &pc_llu))
+ return NULL;
+
+ pc = (CORE_ADDR) pc_llu;
+ sal = find_pc_line (pc, 0);
+ return symtab_and_line_to_sal_object (sal);
+}
"actual" can be deleted now.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-10 21:16 ` Doug Evans
@ 2012-05-11 16:35 ` Siva Chandra
2012-05-11 18:14 ` Doug Evans
0 siblings, 1 reply; 9+ messages in thread
From: Siva Chandra @ 2012-05-11 16:35 UTC (permalink / raw)
To: Doug Evans; +Cc: Eli Zaretskii, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
On Fri, May 11, 2012 at 2:45 AM, Doug Evans <dje@google.com> wrote:
> I think we need to specify what the result is if there is no sal for
> the specified pc.
> ...
> "actual" can be deleted now.
I have addressed these two comments. The patch is attached.
2012-05-11 Siva Chandra Reddy <sivachandra@google.com>
Add a new function gdb.find_pc_line to the Python API.
* NEWS (Python Scripting): Add entry about the new function.
* python/python.c (gdbpy_find_pc_line): New function which
implements gdb.find_pc_line.
(GdbMethods): Add entry for the new function.
doc/
* gdb.texinfo (Basic Python): Add description about the function
gdb.find_pc_line
testsuite/
* gdb.python/python.c: Add a new breakpoint comment.
* gdb.python/python.exp: Add tests to test gdb.find_pc_line.
Thanks,
Siva Chandra
[-- Attachment #2: pc_line_patch_v3.txt --]
[-- Type: text/plain, Size: 4803 bytes --]
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.514
diff -u -p -r1.514 NEWS
--- NEWS 3 May 2012 07:07:24 -0000 1.514
+++ NEWS 11 May 2012 16:29:52 -0000
@@ -43,6 +43,9 @@
which return the global and static blocks (as gdb.Block objects),
of the underlying symbol table, respectively.
+ ** New function gdb.find_pc_line which returns the gdb.Symtab_and_line
+ object associated with a PC value.
+
* Go language support.
GDB now supports debugging programs written in the Go programming
language.
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.957
diff -u -p -r1.957 gdb.texinfo
--- doc/gdb.texinfo 9 May 2012 19:29:25 -0000 1.957
+++ doc/gdb.texinfo 11 May 2012 16:30:15 -0000
@@ -22394,6 +22394,15 @@ compute values, for example, it is the o
convenience variable (@pxref{Convenience Vars}) as a @code{gdb.Value}.
@end defun
+@findex gdb.find_pc_line
+@defun gdb.find_pc_line (pc)
+Return the @code{gdb.Symtab_and_line} object corresponding to the
+@var{pc} value. @xref{Symbol Tables In Python}. If an invalid
+value of @var{pc} is passed as an argument, then the @code{symtab} and
+@code{line} attributes of the returned @code{gdb.Symtab_and_line} object
+will be @code{None} and 0 respectively.
+@end defun
+
@findex gdb.post_event
@defun gdb.post_event (event)
Put @var{event}, a callable object taking no arguments, into
Index: python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/python/python.c,v
retrieving revision 1.86
diff -u -p -r1.86 python.c
--- python/python.c 30 Mar 2012 20:05:55 -0000 1.86
+++ python/python.c 11 May 2012 16:30:16 -0000
@@ -631,6 +631,24 @@ gdbpy_parse_and_eval (PyObject *self, Py
return value_to_value_object (result);
}
+/* Implementation of gdb.find_pc_line function.
+ Returns the gdb.Symtab_and_line object corresponding to a PC value. */
+
+static PyObject *
+gdbpy_find_pc_line (PyObject *self, PyObject *args)
+{
+ struct symtab_and_line sal;
+ CORE_ADDR pc;
+ unsigned long long pc_llu;
+
+ if (!PyArg_ParseTuple (args, GDB_PY_LLU_ARG, &pc_llu))
+ return NULL;
+
+ pc = (CORE_ADDR) pc_llu;
+ sal = find_pc_line (pc, 0);
+ return symtab_and_line_to_sal_object (sal);
+}
+
/* Read a file as Python code.
FILE is the file to run. FILENAME is name of the file FILE.
This does not throw any errors. If an exception occurs python will print
@@ -1458,6 +1476,9 @@ gdb.Symtab_and_line objects (or None)."}
"parse_and_eval (String) -> Value.\n\
Parse String as an expression, evaluate it, and return the result as a Value."
},
+ { "find_pc_line", gdbpy_find_pc_line, METH_VARARGS,
+ "find_pc_line (pc) -> Symtab_and_line.\n\
+Return the gdb.Symtab_and_line object corresponding to the pc value." },
{ "post_event", gdbpy_post_event, METH_VARARGS,
"Post an event into gdb's event loop." },
Index: testsuite/gdb.python/python.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.c,v
retrieving revision 1.4
diff -u -p -r1.4 python.c
--- testsuite/gdb.python/python.c 4 Jan 2012 08:27:49 -0000 1.4
+++ testsuite/gdb.python/python.c 11 May 2012 16:30:19 -0000
@@ -23,6 +23,6 @@ int
main (int argc, char *argv[])
{
func1 ();
- func2 ();
+ func2 (); /* Break at func2 call site. */
return 0; /* Break to end. */
}
Index: testsuite/gdb.python/python.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/python.exp,v
retrieving revision 1.32
diff -u -p -r1.32 python.exp
--- testsuite/gdb.python/python.exp 30 Mar 2012 19:16:52 -0000 1.32
+++ testsuite/gdb.python/python.exp 11 May 2012 16:30:19 -0000
@@ -367,3 +367,23 @@ gdb_test_multiple "python gdb.prompt_hoo
gdb_py_test_silent_cmd "python gdb.prompt_hook = None" \
"set the hook to default" 1
+
+# Start with a fresh gdb.
+clean_restart ${testfile}
+
+# The following tests require execution.
+
+if ![runto_main] then {
+ fail "Can't run to main"
+ return 0
+}
+
+runto [gdb_get_line_number "Break at func2 call site."]
+
+gdb_py_test_silent_cmd "python line = gdb.selected_frame().find_sal().line" "Get line number of func2 call site" 1
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc()).line == line" "True" "Test find_pc_line at func2 call site"
+
+gdb_py_test_silent_cmd "step" "Step into func2" 1
+gdb_py_test_silent_cmd "up" "Step out of func2" 1
+
+gdb_test "python print gdb.find_pc_line(gdb.selected_frame().pc()).line > line" "True" "Test find_pc_line with resume address"
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC] - Exposing find_pc_line through Python API
2012-05-11 16:35 ` Siva Chandra
@ 2012-05-11 18:14 ` Doug Evans
2012-05-13 11:37 ` Siva Chandra
0 siblings, 1 reply; 9+ messages in thread
From: Doug Evans @ 2012-05-11 18:14 UTC (permalink / raw)
To: Siva Chandra; +Cc: Eli Zaretskii, gdb-patches
On Fri, May 11, 2012 at 9:34 AM, Siva Chandra <sivachandra@google.com> wrote:
> On Fri, May 11, 2012 at 2:45 AM, Doug Evans <dje@google.com> wrote:
>> I think we need to specify what the result is if there is no sal for
>> the specified pc.
>> ...
>> "actual" can be deleted now.
>
> I have addressed these two comments. The patch is attached.
>
> 2012-05-11 Siva Chandra Reddy <sivachandra@google.com>
>
> Add a new function gdb.find_pc_line to the Python API.
> * NEWS (Python Scripting): Add entry about the new function.
> * python/python.c (gdbpy_find_pc_line): New function which
> implements gdb.find_pc_line.
> (GdbMethods): Add entry for the new function.
>
> doc/
> * gdb.texinfo (Basic Python): Add description about the function
> gdb.find_pc_line
>
> testsuite/
> * gdb.python/python.c: Add a new breakpoint comment.
> * gdb.python/python.exp: Add tests to test gdb.find_pc_line.
>
> Thanks,
> Siva Chandra
Thanks.
The patch is ok with me.
A question occurred to me, and I'm not suggesting it has to be
answered before the patch can go in.
In vliw architectures one pc value can be associated with multiple
lines (maybe even symtabs, depending on possible future symtab
implementations).
In this particular case I think we can wait until there's a pressing
need to address it.
I just wanted to throw this out there.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-05-13 11:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-07 18:11 [RFC] - Exposing find_pc_line through Python API Siva Chandra
2012-05-07 19:36 ` Eli Zaretskii
2012-05-08 2:35 ` Siva Chandra
2012-05-09 7:35 ` Siva Chandra
2012-05-09 20:05 ` Eli Zaretskii
2012-05-10 21:16 ` Doug Evans
2012-05-11 16:35 ` Siva Chandra
2012-05-11 18:14 ` Doug Evans
2012-05-13 11:37 ` Siva Chandra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox