[RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

The attached patch is a result of discussions here:
    http://sourceware.org/ml/gdb-patches/2012-04/msg00226.html
and here:
    http://sourceware.org/ml/gdb-patches/2012-04/msg00302.html

Code:
2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>

        Add two new methods global_block and static_block to gdb.Symtab
        objects.
        * NEWS (Python scripting): Add entry about the new methods.
        * python/py-symtab.c (stpy_global_block): New function which
        implements the gdb.Symtab.global_block() method.
        (stpy_static_block): New function which implements the
        gdb.Symtab.static_block() method.
        (symtab_object_methods): Add entries for the two new methods.

Testsuite:
2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>

        * py-symbol.exp: Add tests to test the new methods
        gdb.Symtab.global_block() and gdb.Symtab.static_block().
        * py-symbol.c: Add new struct to help test
        gdb.Symtab.static_block().

Docs:
2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>

        * gdb.texinfo (Symbol Tables In Python): Add documentation about
        the new methods global_block and static_block on gdb.Symtab
        objects.

Thanks,
Siva Chandra

[-- Attachment #2: symtab_blocks_patch.txt --]
[-- Type: text/plain, Size: 6483 bytes --]

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.507
diff -u -p -r1.507 NEWS
--- NEWS	11 Apr 2012 05:50:40 -0000	1.507
+++ NEWS	17 Apr 2012 06:01:27 -0000
@@ -32,6 +32,10 @@
   ** A new method 'referenced_value' on gdb.Value objects which can
      dereference pointer as well as C++ reference values.
 
+  ** New methods 'global_block' and 'static_block' on gdb.Symtab objects
+     which return the global and static blocks (as gdb.Block objects),
+     of the underlying symbol table, respectively.
+
 * GDBserver now supports stdio connections.
   E.g. (gdb) target remote | ssh myhost gdbserver - hello
 
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.941
diff -u -p -r1.941 gdb.texinfo
--- doc/gdb.texinfo	14 Apr 2012 12:18:41 -0000	1.941
+++ doc/gdb.texinfo	17 Apr 2012 06:01:33 -0000
@@ -24540,6 +24540,18 @@ if it is invalid at the time the method 
 @defun Symtab.fullname ()
 Return the symbol table's source absolute file name.
 @end defun
+
+@defun Symtab.global_block ()
+Return the global block of the underlying symbol table.  Note that,
+though highly unlikely, the returned @code{gdb.Block} objects are not
+guaranteed to be identical across different @value{GDBN} releases.
+@end defun
+
+@defun Symtab.static_block ()
+Return the static block of the underlying symbol table.  Note that,
+though highly unlikely, the returned @code{gdb.Block} objects are not
+guaranteed to be identical across different @value{GDBN} releases.
+@end defun
 @end table
 
 @node Breakpoints In Python
Index: python/py-symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-symtab.c,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.c
--- python/py-symtab.c	4 Jan 2012 08:17:25 -0000	1.8
+++ python/py-symtab.c	17 Apr 2012 06:01:33 -0000
@@ -23,6 +23,7 @@
 #include "source.h"
 #include "python-internal.h"
 #include "objfiles.h"
+#include "block.h"
 
 typedef struct stpy_symtab_object {
   PyObject_HEAD
@@ -153,6 +154,34 @@ stpy_is_valid (PyObject *self, PyObject 
   Py_RETURN_TRUE;
 }
 
+/* Return the GLOBAL_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_global_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  block = symtab->blockvector->block[GLOBAL_BLOCK];
+  return block_to_block_object (block, symtab->objfile);
+}
+
+/* Return the STATIC_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_static_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  block = symtab->blockvector->block[STATIC_BLOCK];
+  return block_to_block_object (block, symtab->objfile);
+}
+
 static PyObject *
 salpy_str (PyObject *self)
 {
@@ -477,6 +506,12 @@ Return true if this symbol table is vali
   { "fullname", stpy_fullname, METH_NOARGS,
     "fullname () -> String.\n\
 Return the symtab's full source filename." },
+  { "global_block", stpy_global_block, METH_NOARGS,
+    "global_block () -> gdb.Block.\n\
+Return the global block of the symbol table." },
+  { "static_block", stpy_static_block, METH_NOARGS,
+    "static_block () -> gdb.Block.\n\
+Return the static block of the symbol table." },
   {NULL}  /* Sentinel */
 };
 
Index: testsuite/gdb.python/py-symbol.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symbol.c,v
retrieving revision 1.5
diff -u -p -r1.5 py-symbol.c
--- testsuite/gdb.python/py-symbol.c	7 Feb 2012 19:47:16 -0000	1.5
+++ testsuite/gdb.python/py-symbol.c	17 Apr 2012 06:01:34 -0000
@@ -44,6 +44,11 @@ int func (int arg)
   return arg; /* Block break here.  */
 }
 
+struct simple_struct
+{
+  int a;
+};
+
 int main (int argc, char *argv[])
 {
 #ifdef __cplusplus
@@ -51,6 +56,7 @@ int main (int argc, char *argv[])
 #endif
   int a = 0;
   int result;
+  struct simple_struct ss = { 10 };
   enum tag {one, two, three};
   enum tag t = one;
 
Index: testsuite/gdb.python/py-symtab.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symtab.exp,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.exp
--- testsuite/gdb.python/py-symtab.exp	7 Feb 2012 19:42:27 -0000	1.8
+++ testsuite/gdb.python/py-symtab.exp	17 Apr 2012 06:01:34 -0000
@@ -49,6 +49,11 @@ gdb_continue_to_breakpoint "Block break 
 gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0
 gdb_py_test_silent_cmd "python sal = frame.find_sal()" "Get block" 0
 gdb_py_test_silent_cmd "python symtab = sal.symtab" "Get block" 0
+gdb_py_test_silent_cmd "python global_block = symtab.global_block()" "Get global block" 0
+gdb_py_test_silent_cmd "python static_block = symtab.static_block()" "Get static block" 0
+gdb_py_test_silent_cmd "python global_symbols = \[\]; static_symbols = \[\]" "Set up symbol name lists" 0
+gdb_py_test_silent_cmd "python for sym in global_block: global_symbols.append(sym.name)" "Get global symbol names" 0
+gdb_py_test_silent_cmd "python for sym in static_block: static_symbols.append(sym.name)" "Get static symbol names" 0
 
 # Test sal.
 gdb_test "python print sal.symtab" ".*gdb.python/py-symbol.c.*" "Test symtab"
@@ -61,6 +66,12 @@ gdb_test "python print symtab.filename" 
 gdb_test "python print symtab.objfile" "<gdb.Objfile object at ${hex}>" "Test symtab.objfile"
 gdb_test "python print symtab.fullname()" "testsuite/gdb.python/py-symbol.c.*" "Test symtab.fullname"
 gdb_test "python print symtab.is_valid()" "True" "Test symtab.is_valid()"
+gdb_test "python print \"qq\" in global_symbols" "True" "Test qq in global symbols"
+gdb_test "python print \"func\" in global_symbols" "True" "Test func in global symbols"
+gdb_test "python print \"main\" in global_symbols" "True" "Test main in global symbols"
+gdb_test "python print \"int\" in static_symbols" "True" "Test int in static symbols"
+gdb_test "python print \"char\" in static_symbols" "True" "Test char in static symbols"
+gdb_test "python print \"simple_struct\" in static_symbols" "True" "Test simple_struct in static symbols"
 
 # Test is_valid when the objfile is unloaded.  This must be the last
 # test as it unloads the object file in GDB.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Phil Muldoon]

On 04/17/2012 08:25 AM, Siva Chandra wrote:
> The attached patch is a result of discussions here:
>     http://sourceware.org/ml/gdb-patches/2012-04/msg00226.html
> and here:
>     http://sourceware.org/ml/gdb-patches/2012-04/msg00302.html

Thanks, a few comments.

We already have gdb.Block.is_static and gdb.Block.is_global.  I don't
have an objection to this patch per-se, but wouldn't the user acquire
the global/static blocks similarly by iterating the blocks in the
Python code and doing the above tests?
 
> Code:
> 2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>
> 
>         Add two new methods global_block and static_block to gdb.Symtab
>         objects.

I don't think GNU Style ChangeLogs allow for a summary line.  I don't
have an issue with it, but, check with maintainers.  Just a nit.

>         * NEWS (Python scripting): Add entry about the new methods.
>         * python/py-symtab.c (stpy_global_block): New function which
>         implements the gdb.Symtab.global_block() method.
>         (stpy_static_block): New function which implements the
>         gdb.Symtab.static_block() method.
>         (symtab_object_methods): Add entries for the two new methods.
> 
> Testsuite:
> 2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>
> 
>         * py-symbol.exp: Add tests to test the new methods
>         gdb.Symtab.global_block() and gdb.Symtab.static_block().
>         * py-symbol.c: Add new struct to help test
>         gdb.Symtab.static_block().

gdb.python/ prefix to filenames here.
 
> Docs:
> 2012-04-17  Siva Chandra Reddy  <sivachandra@google.com>
> 
>         * gdb.texinfo (Symbol Tables In Python): Add documentation about
>         the new methods global_block and static_block on gdb.Symtab
>         objects.
> 
> Thanks,
> Siva Chandra


> +@defun Symtab.global_block ()
> +Return the global block of the underlying symbol table.  Note that,
> +though highly unlikely, the returned @code{gdb.Block} objects are not
> +guaranteed to be identical across different @value{GDBN} releases.
> +@end defun

In what sense not identical?  I know Doug brought this up, and it is
fair point.  But if I was a Python scripting author it would make me nervous
and distrustful of this API.  

It might also break our API promise, depending on how one looks at it.
What might change? I think mitigation here could be achieved through a
more thorough explanation?  Doug would have to expand on what he thinks
might change.  As it is, this patch makes me a little nervous of
the whole block API in general.

> +@defun Symtab.static_block ()
> +Return the static block of the underlying symbol table.  Note that,
> +though highly unlikely, the returned @code{gdb.Block} objects are not
> +guaranteed to be identical across different @value{GDBN} releases.
> +@end defun

Ditto above.
 
> +static PyObject *
> +stpy_global_block (PyObject *self, PyObject *args)
> +{
> +  struct symtab *symtab = NULL;
> > +  struct block *block = NULL;
> +
> +  STPY_REQUIRE_VALID (self, symtab);
> +
> +  block = symtab->blockvector->block[GLOBAL_BLOCK];
> +  return block_to_block_object (block, symtab->objfile);

I don't think so, but can block ever be NULL here?  Looking at the
code, I'm not even sure if it would matter as set_block just stores a
reference to the passed block.  However, blpy_get_superblock has a
NULL block check, so it might be worthwhile checking it out.

> +  block = symtab->blockvector->block[STATIC_BLOCK];
> +  return block_to_block_object (block, symtab->objfile);

Same as above.

> Index: testsuite/gdb.python/py-symbol.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symbol.c,v
>
> retrieving revision 1.5
> diff -u -p -r1.5 py-symbol.c
 
> Index: testsuite/gdb.python/py-symtab.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symtab.exp,v
> retrieving revision 1.8
> diff -u -p -r1.8 py-symtab.exp

I don't want you to fix this as it is unrelated to your patch, but
.exp files should have their own test inferior.  Something I noted so
I remember to fix it!

Cheers,

Phil

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Thank Phil, for taking a look.  Comments below.

Phil> We already have gdb.Block.is_static and gdb.Block.is_global.  I don't
Phil> have an objection to this patch per-se, but wouldn't the user acquire
Phil> the global/static blocks similarly by iterating the blocks in the
Phil> Python code and doing the above tests?

Is there a way to iterate over all blocks of a Symtab right after
loading?  If yes, my mistake for having missed it, and this patch is
not necessary.  The idea behind most of the patches I am sending is to
have an exploratory path Objfile => Symtab => Block => Symbol.  This
part addresses Symtab => Block part but not completely; good enough
for my immediate needs though.

Phil> I don't think GNU Style ChangeLogs allow for a summary line.  I don't
Phil> have an issue with it, but, check with maintainers.  Just a nit.

There many examples in ChangeLog with a summary line.  There are of
course many others without :-)

>> +static PyObject *
>> +stpy_global_block (PyObject *self, PyObject *args)
>> +{
>> +  struct symtab *symtab = NULL;
>> > +  struct block *block = NULL;
>> +
>> +  STPY_REQUIRE_VALID (self, symtab);
>> +
>> +  block = symtab->blockvector->block[GLOBAL_BLOCK];
>> +  return block_to_block_object (block, symtab->objfile);

Phil> I don't think so, but can block ever be NULL here?  Looking at the
Phil> code, I'm not even sure if it would matter as set_block just stores a
Phil> reference to the passed block.  However, blpy_get_superblock has a
Phil> NULL block check, so it might be worthwhile checking it out.

As I understand, blpy_get_superblock has a check, as the top most
block will not have a superblock.  In which case, returning None is
probably more appropriate (as it is a logically valid situation) than
returning a NULL.  However, in the case of this patch, is there a
chance that a symtab->blockvector->nblocks == 0?  Similarly, is there
a chance blockvector->nblocks > 0 but blockvector->block[GLOBAL_BLOCK]
(or blockvector->block[STATIC_BLOCK]) is NULL for a logical valid
situation?

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> Is there a way to iterate over all blocks of a Symtab right after
Siva> loading?

Nope.

Siva> This part addresses Symtab => Block part but not completely; good
Siva> enough for my immediate needs though.

I'm curious if you're going to implement iteration over sub-blocks.

Siva> However, in the case of this patch, is there a
Siva> chance that a symtab->blockvector->nblocks == 0?

I don't believe so.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> We already have gdb.Block.is_static and gdb.Block.is_global.  I don't
Phil> have an objection to this patch per-se, but wouldn't the user acquire
Phil> the global/static blocks similarly by iterating the blocks in the
Phil> Python code and doing the above tests?
 
He wants to be able to iterate over the blocks in a symtab.
Right now there is no way to do this, since there's no way to get a
good starting point.

So, these methods provide that access.  They are complementary to the
methods on Block.

Phil> gdb.python/ prefix to filenames here.
 
Oh yeah, I missed that one.
Thanks.

>> +  block = symtab->blockvector->block[GLOBAL_BLOCK];
>> +  return block_to_block_object (block, symtab->objfile);

Phil> I don't think so, but can block ever be NULL here?

I don't think so.

Phil> However, blpy_get_superblock has a NULL block check, so it might
Phil> be worthwhile checking it out.

I think that is different because the global block's superblock is NULL.

>> +  block = symtab->blockvector->block[STATIC_BLOCK];
>> +  return block_to_block_object (block, symtab->objfile);

Phil> Same as above.

Ditto.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Eli Zaretskii]

> Date: Tue, 17 Apr 2012 12:55:43 +0530
> From: Siva Chandra <sivachandra@google.com>
> 
> +  ** New methods 'global_block' and 'static_block' on gdb.Symtab objects
> +     which return the global and static blocks (as gdb.Block objects),
> +     of the underlying symbol table, respectively.

This is OK.

> +@defun Symtab.global_block ()
> +Return the global block of the underlying symbol table.  Note that,
> +though highly unlikely, the returned @code{gdb.Block} objects are not
> +guaranteed to be identical across different @value{GDBN} releases.
> +@end defun
> +
> +@defun Symtab.static_block ()
> +Return the static block of the underlying symbol table.  Note that,
> +though highly unlikely, the returned @code{gdb.Block} objects are not
> +guaranteed to be identical across different @value{GDBN} releases.
> +@end defun

I think it would be a good idea to have here a cross-reference to
"Blocks in Python".

Also, the 2 identical sentences about the objects not being preserved
across GDB releases should probably be replaced by just one sentence,
saying this for both types of blocks.

The documentation parts are OK with those changes.

Thanks.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

>> +@defun Symtab.global_block ()
>> +Return the global block of the underlying symbol table.  Note that,
>> +though highly unlikely, the returned @code{gdb.Block} objects are not
>> +guaranteed to be identical across different @value{GDBN} releases.
>> +@end defun
>> +
>> +@defun Symtab.static_block ()
>> +Return the static block of the underlying symbol table.  Note that,
>> +though highly unlikely, the returned @code{gdb.Block} objects are not
>> +guaranteed to be identical across different @value{GDBN} releases.
>> +@end defun

Eli> I think it would be a good idea to have here a cross-reference to
Eli> "Blocks in Python".
Eli>
Eli> Also, the 2 identical sentences about the objects not being preserved
Eli> across GDB releases should probably be replaced by just one sentence,
Eli> saying this for both types of blocks.

Thanks Eli, for taking a look.  I have modified according to your
comments.  I would like you to take a look at the doc changes again
since the suggestion wasn't objective for the second change.
ChangeLog correction pointed to by Phil, and the use of accessor
macros as suggested by Tom, are also in the attached patch.

Code:
2012-04-18  Siva Chandra Reddy  <sivachandra@google.com>

       Add two new methods global_block and static_block to gdb.Symtab
       objects.
       * NEWS (Python scripting): Add entry about the new methods.
       * python/py-symtab.c (stpy_global_block): New function which
       implements the gdb.Symtab.global_block() method.
       (stpy_static_block): New function which implements the
       gdb.Symtab.static_block() method.
       (symtab_object_methods): Add entries for the two new methods.

Testsuite:
2012-04-18  Siva Chandra Reddy  <sivachandra@google.com>

       * gdb.python/py-symbol.exp: Add tests to test the new methods
       gdb.Symtab.global_block() and gdb.Symtab.static_block().
       * gdb.python/py-symbol.c: Add new struct to help test
       gdb.Symtab.static_block().

Docs:
2012-04-18  Siva Chandra Reddy  <sivachandra@google.com>

       * gdb.texinfo (Symbol Tables In Python): Add documentation about
       the new methods global_block and static_block on gdb.Symtab
       objects.

Thanks,
Siva Chandra

[-- Attachment #2: symtab_blocks_patch_v2.txt --]
[-- Type: text/plain, Size: 6682 bytes --]

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.510
diff -u -p -r1.510 NEWS
--- NEWS	17 Apr 2012 15:56:21 -0000	1.510
+++ NEWS	18 Apr 2012 06:27:16 -0000
@@ -32,6 +32,10 @@
   ** A new method 'referenced_value' on gdb.Value objects which can
      dereference pointer as well as C++ reference values.
 
+  ** New methods 'global_block' and 'static_block' on gdb.Symtab objects
+     which return the global and static blocks (as gdb.Block objects),
+     of the underlying symbol table, respectively.
+
 * GDBserver now supports stdio connections.
   E.g. (gdb) target remote | ssh myhost gdbserver - hello
 
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.944
diff -u -p -r1.944 gdb.texinfo
--- doc/gdb.texinfo	17 Apr 2012 15:56:21 -0000	1.944
+++ doc/gdb.texinfo	18 Apr 2012 06:27:55 -0000
@@ -24920,8 +24920,23 @@ if it is invalid at the time the method 
 @defun Symtab.fullname ()
 Return the symbol table's source absolute file name.
 @end defun
+
+@defun Symtab.global_block ()
+Return the global block of the underlying symbol table.
+@xref{Blocks In Python}.
+@end defun
+
+@defun Symtab.static_block ()
+Return the static block of the underlying symbol table.
+@xref{Blocks In Python}.
+@end defun
 @end table
 
+Note that, though highly unlikely, the @code{gdb.Block} objects returned
+by the methods @code{Symtab.global_block ()} and
+@code{Symtab.static_block ()} are not guaranteed to be identical across
+different @value{GDBN} releases.
+
 @node Breakpoints In Python
 @subsubsection Manipulating breakpoints using Python
 
Index: python/py-symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-symtab.c,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.c
--- python/py-symtab.c	4 Jan 2012 08:17:25 -0000	1.8
+++ python/py-symtab.c	18 Apr 2012 06:27:55 -0000
@@ -23,6 +23,7 @@
 #include "source.h"
 #include "python-internal.h"
 #include "objfiles.h"
+#include "block.h"
 
 typedef struct stpy_symtab_object {
   PyObject_HEAD
@@ -153,6 +154,38 @@ stpy_is_valid (PyObject *self, PyObject 
   Py_RETURN_TRUE;
 }
 
+/* Return the GLOBAL_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_global_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+  struct blockvector *blockvector;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  blockvector = BLOCKVECTOR (symtab);
+  block = BLOCKVECTOR_BLOCK (blockvector, GLOBAL_BLOCK);
+  return block_to_block_object (block, symtab->objfile);
+}
+
+/* Return the STATIC_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_static_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+  struct blockvector *blockvector;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  blockvector = BLOCKVECTOR (symtab);
+  block = BLOCKVECTOR_BLOCK (blockvector, STATIC_BLOCK);
+  return block_to_block_object (block, symtab->objfile);
+}
+
 static PyObject *
 salpy_str (PyObject *self)
 {
@@ -477,6 +510,12 @@ Return true if this symbol table is vali
   { "fullname", stpy_fullname, METH_NOARGS,
     "fullname () -> String.\n\
 Return the symtab's full source filename." },
+  { "global_block", stpy_global_block, METH_NOARGS,
+    "global_block () -> gdb.Block.\n\
+Return the global block of the symbol table." },
+  { "static_block", stpy_static_block, METH_NOARGS,
+    "static_block () -> gdb.Block.\n\
+Return the static block of the symbol table." },
   {NULL}  /* Sentinel */
 };
 
Index: testsuite/gdb.python/py-symbol.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symbol.c,v
retrieving revision 1.5
diff -u -p -r1.5 py-symbol.c
--- testsuite/gdb.python/py-symbol.c	7 Feb 2012 19:47:16 -0000	1.5
+++ testsuite/gdb.python/py-symbol.c	18 Apr 2012 06:27:56 -0000
@@ -44,6 +44,11 @@ int func (int arg)
   return arg; /* Block break here.  */
 }
 
+struct simple_struct
+{
+  int a;
+};
+
 int main (int argc, char *argv[])
 {
 #ifdef __cplusplus
@@ -51,6 +56,7 @@ int main (int argc, char *argv[])
 #endif
   int a = 0;
   int result;
+  struct simple_struct ss = { 10 };
   enum tag {one, two, three};
   enum tag t = one;
 
Index: testsuite/gdb.python/py-symtab.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symtab.exp,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.exp
--- testsuite/gdb.python/py-symtab.exp	7 Feb 2012 19:42:27 -0000	1.8
+++ testsuite/gdb.python/py-symtab.exp	18 Apr 2012 06:27:56 -0000
@@ -49,6 +49,11 @@ gdb_continue_to_breakpoint "Block break 
 gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0
 gdb_py_test_silent_cmd "python sal = frame.find_sal()" "Get block" 0
 gdb_py_test_silent_cmd "python symtab = sal.symtab" "Get block" 0
+gdb_py_test_silent_cmd "python global_block = symtab.global_block()" "Get global block" 0
+gdb_py_test_silent_cmd "python static_block = symtab.static_block()" "Get static block" 0
+gdb_py_test_silent_cmd "python global_symbols = \[\]; static_symbols = \[\]" "Set up symbol name lists" 0
+gdb_py_test_silent_cmd "python for sym in global_block: global_symbols.append(sym.name)" "Get global symbol names" 0
+gdb_py_test_silent_cmd "python for sym in static_block: static_symbols.append(sym.name)" "Get static symbol names" 0
 
 # Test sal.
 gdb_test "python print sal.symtab" ".*gdb.python/py-symbol.c.*" "Test symtab"
@@ -61,6 +66,12 @@ gdb_test "python print symtab.filename" 
 gdb_test "python print symtab.objfile" "<gdb.Objfile object at ${hex}>" "Test symtab.objfile"
 gdb_test "python print symtab.fullname()" "testsuite/gdb.python/py-symbol.c.*" "Test symtab.fullname"
 gdb_test "python print symtab.is_valid()" "True" "Test symtab.is_valid()"
+gdb_test "python print \"qq\" in global_symbols" "True" "Test qq in global symbols"
+gdb_test "python print \"func\" in global_symbols" "True" "Test func in global symbols"
+gdb_test "python print \"main\" in global_symbols" "True" "Test main in global symbols"
+gdb_test "python print \"int\" in static_symbols" "True" "Test int in static symbols"
+gdb_test "python print \"char\" in static_symbols" "True" "Test char in static symbols"
+gdb_test "python print \"simple_struct\" in static_symbols" "True" "Test simple_struct in static symbols"
 
 # Test is_valid when the objfile is unloaded.  This must be the last
 # test as it unloads the object file in GDB.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Phil Muldoon]

On 04/18/2012 09:49 AM, Siva Chandra wrote:
>>> +@defun Symtab.global_block ()
>>> +Return the global block of the underlying symbol table.  Note that,
>>> +though highly unlikely, the returned @code{gdb.Block} objects are not
>>> +guaranteed to be identical across different @value{GDBN} releases.
>>> +@end defun
>>> +
>>> +@defun Symtab.static_block ()
>>> +Return the static block of the underlying symbol table.  Note that,
>>> +though highly unlikely, the returned @code{gdb.Block} objects are not
>>> +guaranteed to be identical across different @value{GDBN} releases.
>>> +@end defun
> 
> Eli> I think it would be a good idea to have here a cross-reference to
> Eli> "Blocks in Python".
> Eli>
> Eli> Also, the 2 identical sentences about the objects not being preserved
> Eli> across GDB releases should probably be replaced by just one sentence,
> Eli> saying this for both types of blocks.
> 
> Thanks Eli, for taking a look.  I have modified according to your
> comments.  I would like you to take a look at the doc changes again
> since the suggestion wasn't objective for the second change.
> ChangeLog correction pointed to by Phil, and the use of accessor
> macros as suggested by Tom, are also in the attached patch.

FWIW, I would still like to see a clarification of the static/global
documentation regarding the "this might change" comment.  Sorry to be
a stickler on this, but I think it is important we don't start hinting
at API breakages without an adequate explanation as to what may
change, and why.  (Given that there is a need to put that disclaimer
in there in the first place).

Cheers,

Phil

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> FWIW, I would still like to see a clarification of the static/global
Phil> documentation regarding the "this might change" comment.  Sorry to be
Phil> a stickler on this, but I think it is important we don't start hinting
Phil> at API breakages without an adequate explanation as to what may
Phil> change, and why.  (Given that there is a need to put that disclaimer
Phil> in there in the first place).

Thanks Phil.
I agree this text is a bit on the terse side.

An issue I see with it is that, as a Python developer, you can't take
any action to insulate yourself.  Perhaps being more specific about what
"identical" means would be useful.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Phil> FWIW, I would still like to see a clarification of the static/global
Phil> documentation regarding the "this might change" comment.  Sorry to be
Phil> a stickler on this, but I think it is important we don't start hinting
Phil> at API breakages without an adequate explanation as to what may
Phil> change, and why.  (Given that there is a need to put that disclaimer
Phil> in there in the first place).

Tom> I agree this text is a bit on the terse side.
Tom>
Tom> An issue I see with it is that, as a Python developer, you can't take
Tom> any action to insulate yourself.  Perhaps being more specific about what
Tom> "identical" means would be useful.

OK. I will wait for Doug to clarify on this.

/Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Doug Evans]

On Thu, Apr 19, 2012 at 10:29 AM, Siva Chandra <sivachandra@google.com> wrote:
> Phil> FWIW, I would still like to see a clarification of the static/global
> Phil> documentation regarding the "this might change" comment.  Sorry to be
> Phil> a stickler on this, but I think it is important we don't start hinting
> Phil> at API breakages without an adequate explanation as to what may
> Phil> change, and why.  (Given that there is a need to put that disclaimer
> Phil> in there in the first place).
>
> Tom> I agree this text is a bit on the terse side.
> Tom>
> Tom> An issue I see with it is that, as a Python developer, you can't take
> Tom> any action to insulate yourself.  Perhaps being more specific about what
> Tom> "identical" means would be useful.
>
> OK. I will wait for Doug to clarify on this.
>
> /Siva Chandra

It would not be unexpected to me if a symbol disappeared from either
list, moved from one list to another, or a new symbol appeared.

[I also think exposing "global" vs "static" is an implementation
detail, and thus shouldn't be part of the API, akin to exposing symbol
table file names - symbols can have file names (like they have line
numbers), but symbol tables I'm less comfortable with.  Both of those
ships have already sailed, I know.]

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Doug> It would not be unexpected to me if a symbol disappeared from either
Doug> list, moved from one list to another, or a new symbol appeared.

Even in the API currently public, Block.superblock can take a user to
global or static block and make him/her vulnerable to the above
problem.  But, can we view this from a different angle:  Let us first
take the case of a global block.  As I understand, this should very
definitely contain the global functions and global variables defined
in a source file.  If these two kinds of symbols do not change from
release to release, then we document saying that the user should rely
only on this information being constant.  Similarly, if my
understanding is correct, static functions and static variables
defined in a source file should always be present in a static block.
Hence, we again document saying that the user rely only on this
information being constant.  Does this sound reasonable?

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Matt Rice]

On Thu, Apr 19, 2012 at 9:57 PM, Siva Chandra <sivachandra@google.com> wrote:

>  Similarly, if my
> understanding is correct, static functions and static variables
> defined in a source file should always be present in a static block.
> Hence, we again document saying that the user rely only on this
> information being constant.  Does this sound reasonable?

I personally don't know a lot about this area, but I do recall seeing
some comments which hint at the unreliability in this.

I can't find the specific comment I went looking for,
which I recall as saying that sometimes it is a 'best guess'.  could
be a figment of my imagination

the following from (possibly outdated) symtab.c stuff is what i did
find, i believe there is other uncommented occurrences, anyhow given
the fudge and lack of errors I wouldn't be suprised to weirdness here
go unnoticed.



      int other_kind = kind == GLOBAL_BLOCK ? STATIC_BLOCK : GLOBAL_BLOCK;

      /* This shouldn't be necessary, but as a last resort
       * try looking in the 'other kind' even though the psymtab
       * claimed the symbol was one thing.  It's possible that
       * the psymtab gets it wrong in some cases.
       */
      block = BLOCKVECTOR_BLOCK (bv, other_kind);
      sym = lookup_block_symbol (block, name, STRUCT_DOMAIN);

....

      /* This shouldn't be necessary, but as a last resort try
         looking in the statics even though the psymtab claimed
         the symbol was global, or vice-versa.  It's possible
         that the psymtab gets it wrong in some cases.  */

      /* FIXME: carlton/2002-09-30: Should we really do that?
         If that happens, isn't it likely to be a GDB error, in
         which case we should fix the GDB error rather than
         silently dealing with it here?  So I'd vote for
         removing the check for the symbol in the other
         block.  */
      block = BLOCKVECTOR_BLOCK (bv,
                                 kind == GLOBAL_BLOCK ?
                                 STATIC_BLOCK : GLOBAL_BLOCK);

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Doug Evans]

On Fri, Apr 20, 2012 at 4:43 AM, Matt Rice <ratmice@gmail.com> wrote:
>      /* This shouldn't be necessary, but as a last resort
>       * try looking in the 'other kind' even though the psymtab
>       * claimed the symbol was one thing.  It's possible that
>       * the psymtab gets it wrong in some cases.
>       */
>      block = BLOCKVECTOR_BLOCK (bv, other_kind);
>      sym = lookup_block_symbol (block, name, STRUCT_DOMAIN);
>
> ....
>
>      /* This shouldn't be necessary, but as a last resort try
>         looking in the statics even though the psymtab claimed
>         the symbol was global, or vice-versa.  It's possible
>         that the psymtab gets it wrong in some cases.  */
>
>      /* FIXME: carlton/2002-09-30: Should we really do that?
>         If that happens, isn't it likely to be a GDB error, in
>         which case we should fix the GDB error rather than
>         silently dealing with it here?  So I'd vote for
>         removing the check for the symbol in the other
>         block.  */
>      block = BLOCKVECTOR_BLOCK (bv,
>                                 kind == GLOBAL_BLOCK ?
>                                 STATIC_BLOCK : GLOBAL_BLOCK);

That reminds me, thanks!
[Assuming I'm remembering correctly, can be dangerous at times :-)]
The cost of this can be, umm, quite depressing.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Matt Rice]

On Fri, Apr 20, 2012 at 4:43 AM, Matt Rice <ratmice@gmail.com> wrote:

> I can't find the specific comment I went looking for,
> which I recall as saying that sometimes it is a 'best guess'.  could
> be a figment of my imagination

Ahh, i remembered that this was the comment at the top of
enum minimal_symbol_type, which is likely to be completely unrelated
to the topic.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:

Matt> the following from (possibly outdated) symtab.c stuff is what i did
Matt> find, i believe there is other uncommented occurrences, anyhow given
Matt> the fudge and lack of errors I wouldn't be suprised to weirdness here
Matt> go unnoticed.

I've always assumed these comments are just wrong.
If this can really happen, then the bug should be fixed in the symbol
readers, not hacked around elsewhere.  IMNSHO of course.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Doug Evans]

On Fri, Apr 20, 2012 at 12:04 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:
>
> Matt> the following from (possibly outdated) symtab.c stuff is what i did
> Matt> find, i believe there is other uncommented occurrences, anyhow given
> Matt> the fudge and lack of errors I wouldn't be suprised to weirdness here
> Matt> go unnoticed.
>
> I've always assumed these comments are just wrong.
> If this can really happen, then the bug should be fixed in the symbol
> readers, not hacked around elsewhere.  IMNSHO of course.

Yep.
Something I hope attention to the symbol handling will dig into.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Siva> Similarly, if my
Siva> understanding is correct, static functions and static variables
Siva> defined in a source file should always be present in a static block.
Siva> Hence, we again document saying that the user rely only on this
Siva> information being constant.  Does this sound reasonable?

Matt> the following from (possibly outdated) symtab.c stuff is what i did
Matt> find, i believe there is other uncommented occurrences, anyhow given
Matt> the fudge and lack of errors I wouldn't be suprised to weirdness here
Matt> go unnoticed.

Tom> I've always assumed these comments are just wrong.
Tom> If this can really happen, then the bug should be fixed in the symbol
Tom> readers, not hacked around elsewhere.  IMNSHO of course.

Doug> Yep.
Doug> Something I hope attention to the symbol handling will dig into.

To be frank, I do not understand much of the code in dwarf2read.c yet.
 However, I focused on functions and variables in my comment because
LOCAL and GLOBAL bindings in a file are present right in the ELF
.symtab section. If at all something is not being classified correctly
in GDB, then it should be a bug  (not necessarily in GDB?).  I did not
talk about types because they are treated as static when compiled as a
C program, and as global when compiled as a C++ program (in fact, I
thought this was Doug's concern to begin with!).

Overall, wrt this patch, what should we conclude?

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> Overall, wrt this patch, what should we conclude?

I think the patch is fine, and we're just discussing what exactly the
manual should say.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Phil Muldoon]

On 04/23/2012 02:17 PM, Tom Tromey wrote:
>>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
> 
> Siva> Overall, wrt this patch, what should we conclude?
> 
> I think the patch is fine, and we're just discussing what exactly the
> manual should say.

My view is that we should not say anything, that it will just be
confusing to the user.  There is no user facing concept of a "static"
or "global" block in GDB other than the Python API anyway. We have to
keep API compatibility, so if the implementation were to change
in GDB, we would have to just manage that change in the Python
bindings (like we currently do now).  There are many abstract
concepts, that can be subject to change already (things like Program
Spaces).

Cheers,

Phil

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Eli Zaretskii]

> Date: Mon, 23 Apr 2012 14:30:02 +0100
> From: Phil Muldoon <pmuldoon@redhat.com>
> CC: Siva Chandra <sivachandra@google.com>, Doug Evans <dje@google.com>,
>         Matt Rice <ratmice@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>         gdb-patches@sourceware.org
> 
> On 04/23/2012 02:17 PM, Tom Tromey wrote:
> >>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
> > 
> > Siva> Overall, wrt this patch, what should we conclude?
> > 
> > I think the patch is fine, and we're just discussing what exactly the
> > manual should say.
> 
> My view is that we should not say anything, that it will just be
> confusing to the user.  There is no user facing concept of a "static"
> or "global" block in GDB other than the Python API anyway.

We cannot have 2 separate APIs, one called Symtab.global_block, the
other Symtab.static_block, without saying at least _something_ about
what these names are about.

Also, the Python API to GDB _is_ user-level.

Apologies if I am missing the context of what you said.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Phil Muldoon]

On 04/23/2012 02:55 PM, Eli Zaretskii wrote:
>> Date: Mon, 23 Apr 2012 14:30:02 +0100
>> From: Phil Muldoon <pmuldoon@redhat.com>
>> CC: Siva Chandra <sivachandra@google.com>, Doug Evans <dje@google.com>,
>>         Matt Rice <ratmice@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>>         gdb-patches@sourceware.org
>>
>> On 04/23/2012 02:17 PM, Tom Tromey wrote:
>>>>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
>>>
>>> Siva> Overall, wrt this patch, what should we conclude?
>>>
>>> I think the patch is fine, and we're just discussing what exactly the
>>> manual should say.
>>
>> My view is that we should not say anything, that it will just be
>> confusing to the user.  There is no user facing concept of a "static"
>> or "global" block in GDB other than the Python API anyway.
> 
> We cannot have 2 separate APIs, one called Symtab.global_block, the
> other Symtab.static_block, without saying at least _something_ about
> what these names are about.
> 
> Also, the Python API to GDB _is_ user-level.
> 
> Apologies if I am missing the context of what you said.

I agree, and we have documentation and an API for is_static block and
is_global block APIs already.  Describing what they are now,
contextually, is fine -- no problem with that.  I am just not sure we
should have compatibility warnings that the content/structure of these
blocks may change in some undefined way, at some future time.  I think
we should document it when, and if that happens, and what, if any,
ramifications may occur. 

Arguable the above warning could apply to most of the Python API.  We
tend to just deal with it in the API when it happens.  While I
understand the well-meaning thought behind this, I am not sure it is
prudent to start this trend now.  We have an API promise to
specifically deal with these issues.  If we start warning that in the
future this feature might change, are we just creating loop-holes for
the API promise?  In fact my benchmark for exporting something to the
Python API is testing the likely-hood if it will change in the near
future.  But, to date, I find that most of GDB remains fairly
constant.

And finally, yeah that is what I mean: Python is the only user-facing
API for these attributes.  There is no conflict between something in
the CLI and something in Python.

Cheers,

Phil

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Eli Zaretskii]

> Date: Mon, 23 Apr 2012 15:11:25 +0100
> From: Phil Muldoon <pmuldoon@redhat.com>
> CC: tromey@redhat.com, sivachandra@google.com, dje@google.com,
>         ratmice@gmail.com, gdb-patches@sourceware.org
> 
> I am just not sure we should have compatibility warnings that the
> content/structure of these blocks may change in some undefined way,
> at some future time.

With that I agree.  Saying such things in a manual is never a good
idea, unless we also describe in detail what exactly can go wrong, how
to detect that, and how to work around.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

On Mon, Apr 23, 2012 at 8:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> With that I agree.  Saying such things in a manual is never a good
> idea, unless we also describe in detail what exactly can go wrong, how
> to detect that, and how to work around.

So, can I go ahead and commit after removing the 'controversial' part
from the doc?

I can add descriptions about what global and static blocks are under
"Blocks In Python" (there are xrefs from Symtab.*_block to "Blocks In
Python" now) as a different patch. (?)

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Eli Zaretskii]

> Date: Tue, 24 Apr 2012 12:40:35 +0530
> From: Siva Chandra <sivachandra@google.com>
> Cc: Phil Muldoon <pmuldoon@redhat.com>, tromey@redhat.com, dje@google.com, 
> 	ratmice@gmail.com, gdb-patches@sourceware.org
> 
> On Mon, Apr 23, 2012 at 8:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > With that I agree.  Saying such things in a manual is never a good
> > idea, unless we also describe in detail what exactly can go wrong, how
> > to detect that, and how to work around.
> 
> So, can I go ahead and commit after removing the 'controversial' part
> from the doc?

Fine with me, if others agree.

> I can add descriptions about what global and static blocks are under
> "Blocks In Python" (there are xrefs from Symtab.*_block to "Blocks In
> Python" now) as a different patch. (?)

Yes, that would be good (and yes, as a separate changeset).

Thanks.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

Phil> I am just not sure we should have compatibility warnings that the
Phil> content/structure of these blocks may change in some undefined way,
Phil> at some future time.

Eli> With that I agree.  Saying such things in a manual is never a good
Eli> idea, unless we also describe in detail what exactly can go wrong, how
Eli> to detect that, and how to work around.

I think the difficulty here is that saying nothing may also lull Python
users into a false sense of security that we will not change things in
this area.

But, we'd still like the freedom to change things.  For example, we've
talked off and on about implementing "hierarchical" symbol tables, where
the symbols in a namespace (e.g.) are kept in the namespace symbol, not
globally.

If we made this sort of change, then iterating over the block would
return different results.

Maybe there is some way to rewrite the original text to give us some
leeway.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Phil> I am just not sure we should have compatibility warnings that the
Phil> content/structure of these blocks may change in some undefined way,
Phil> at some future time.

Eli> With that I agree.  Saying such things in a manual is never a good
Eli> idea, unless we also describe in detail what exactly can go wrong, how
Eli> to detect that, and how to work around.

Tom> I think the difficulty here is that saying nothing may also lull Python
Tom> users into a false sense of security that we will not change things in
Tom> this area.

Tom> But, we'd still like the freedom to change things.  For example, we've
Tom> talked off and on about implementing "hierarchical" symbol tables, where
Tom> the symbols in a namespace (e.g.) are kept in the namespace symbol, not
Tom> globally.

Tom> If we made this sort of change, then iterating over the block would
Tom> return different results.

Tom> Maybe there is some way to rewrite the original text to give us some
Tom> leeway.

Does this look good: http://sourceware.org/ml/gdb-patches/2012-04/msg00847.html

It adds a general note about symbols in a block under 'Blocks In Python'.

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

On Wed, Apr 25, 2012 at 12:06 PM, Tom Tromey <tromey@redhat.com> wrote:
> I think the difficulty here is that saying nothing may also lull Python
> users into a false sense of security that we will not change things in
> this area.
>
> But, we'd still like the freedom to change things.  For example, we've
> talked off and on about implementing "hierarchical" symbol tables, where
> the symbols in a namespace (e.g.) are kept in the namespace symbol, not
> globally.
>
> If we made this sort of change, then iterating over the block would
> return different results.
>
> Maybe there is some way to rewrite the original text to give us some
> leeway.

Does this note to user need to be a part of this patch?

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Doug Evans]

On Thu, Apr 26, 2012 at 4:56 AM, Siva Chandra <sivachandra@google.com> wrote:
> On Wed, Apr 25, 2012 at 12:06 PM, Tom Tromey <tromey@redhat.com> wrote:
>> I think the difficulty here is that saying nothing may also lull Python
>> users into a false sense of security that we will not change things in
>> this area.
>>
>> But, we'd still like the freedom to change things.  For example, we've
>> talked off and on about implementing "hierarchical" symbol tables, where
>> the symbols in a namespace (e.g.) are kept in the namespace symbol, not
>> globally.
>>
>> If we made this sort of change, then iterating over the block would
>> return different results.
>>
>> Maybe there is some way to rewrite the original text to give us some
>> leeway.
>
> Does this note to user need to be a part of this patch?

fwiw, my opinion is "No.".
That would just be making you put too much effort into form over substance.
If you want to, go for it.  But it's not necessary (IMO).

We may want to hold off checking things in until the doc text is ready though.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Tom> I think the difficulty here is that saying nothing may also lull Python
Tom> users into a false sense of security that we will not change things in
Tom> this area.

Tom> But, we'd still like the freedom to change things.  For example, we've
Tom> talked off and on about implementing "hierarchical" symbol tables, where
Tom> the symbols in a namespace (e.g.) are kept in the namespace symbol, not
Tom> globally.

Tom> If we made this sort of change, then iterating over the block would
Tom> return different results.

Tom> Maybe there is some way to rewrite the original text to give us some
Tom> leeway.

Siva> Does this note to user need to be a part of this patch?

Doug> fwiw, my opinion is "No.".
Doug> That would just be making you put too much effort into form over
substance.
Doug> If you want to, go for it.  But it's not necessary (IMO).
Doug> We may want to hold off checking things in until the doc text is
ready though.

Now that the note to the user is in, is this patch ready to go in as
well?  Tom and Eli have already OK-ed, but I am double checking as it
has been a while since then.

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Doug Evans]

On Wed, May 2, 2012 at 10:40 AM, Siva Chandra <sivachandra@google.com> wrote:
> Now that the note to the user is in, is this patch ready to go in as
> well?  Tom and Eli have already OK-ed, but I am double checking as it
> has been a while since then.

I think the patch is ok to go in (ref: Tom and Eli have OK'd it).

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

Siva> Now that the note to the user is in, is this patch ready to go in as
Siva> well?  Tom and Eli have already OK-ed, but I am double checking as it
Siva> has been a while since then.

Doug> I think the patch is ok to go in (ref: Tom and Eli have OK'd it).

Committed. Attached the patch for reference.

Thanks,
Siva Chandra

[-- Attachment #2: symtab_blocks_patch_final.txt --]
[-- Type: text/plain, Size: 6387 bytes --]

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.513
diff -u -p -r1.513 NEWS
--- NEWS	27 Apr 2012 20:47:51 -0000	1.513
+++ NEWS	3 May 2012 06:47:15 -0000
@@ -39,6 +39,10 @@
   ** A new method 'referenced_value' on gdb.Value objects which can
      dereference pointer as well as C++ reference values.
 
+  ** New methods 'global_block' and 'static_block' on gdb.Symtab objects
+     which return the global and static blocks (as gdb.Block objects),
+     of the underlying symbol table, respectively.
+
 * 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.953
diff -u -p -r1.953 gdb.texinfo
--- doc/gdb.texinfo	2 May 2012 17:27:50 -0000	1.953
+++ doc/gdb.texinfo	3 May 2012 06:47:35 -0000
@@ -25038,6 +25038,16 @@ if it is invalid at the time the method 
 @defun Symtab.fullname ()
 Return the symbol table's source absolute file name.
 @end defun
+
+@defun Symtab.global_block ()
+Return the global block of the underlying symbol table.
+@xref{Blocks In Python}.
+@end defun
+
+@defun Symtab.static_block ()
+Return the static block of the underlying symbol table.
+@xref{Blocks In Python}.
+@end defun
 @end table
 
 @node Breakpoints In Python
Index: python/py-symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-symtab.c,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.c
--- python/py-symtab.c	4 Jan 2012 08:17:25 -0000	1.8
+++ python/py-symtab.c	3 May 2012 06:47:36 -0000
@@ -23,6 +23,7 @@
 #include "source.h"
 #include "python-internal.h"
 #include "objfiles.h"
+#include "block.h"
 
 typedef struct stpy_symtab_object {
   PyObject_HEAD
@@ -153,6 +154,38 @@ stpy_is_valid (PyObject *self, PyObject 
   Py_RETURN_TRUE;
 }
 
+/* Return the GLOBAL_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_global_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+  struct blockvector *blockvector;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  blockvector = BLOCKVECTOR (symtab);
+  block = BLOCKVECTOR_BLOCK (blockvector, GLOBAL_BLOCK);
+  return block_to_block_object (block, symtab->objfile);
+}
+
+/* Return the STATIC_BLOCK of the underlying symtab.  */
+
+static PyObject *
+stpy_static_block (PyObject *self, PyObject *args)
+{
+  struct symtab *symtab = NULL;
+  struct block *block = NULL;
+  struct blockvector *blockvector;
+
+  STPY_REQUIRE_VALID (self, symtab);
+
+  blockvector = BLOCKVECTOR (symtab);
+  block = BLOCKVECTOR_BLOCK (blockvector, STATIC_BLOCK);
+  return block_to_block_object (block, symtab->objfile);
+}
+
 static PyObject *
 salpy_str (PyObject *self)
 {
@@ -477,6 +510,12 @@ Return true if this symbol table is vali
   { "fullname", stpy_fullname, METH_NOARGS,
     "fullname () -> String.\n\
 Return the symtab's full source filename." },
+  { "global_block", stpy_global_block, METH_NOARGS,
+    "global_block () -> gdb.Block.\n\
+Return the global block of the symbol table." },
+  { "static_block", stpy_static_block, METH_NOARGS,
+    "static_block () -> gdb.Block.\n\
+Return the static block of the symbol table." },
   {NULL}  /* Sentinel */
 };
 
Index: testsuite/gdb.python/py-symbol.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symbol.c,v
retrieving revision 1.5
diff -u -p -r1.5 py-symbol.c
--- testsuite/gdb.python/py-symbol.c	7 Feb 2012 19:47:16 -0000	1.5
+++ testsuite/gdb.python/py-symbol.c	3 May 2012 06:47:38 -0000
@@ -44,6 +44,11 @@ int func (int arg)
   return arg; /* Block break here.  */
 }
 
+struct simple_struct
+{
+  int a;
+};
+
 int main (int argc, char *argv[])
 {
 #ifdef __cplusplus
@@ -51,6 +56,7 @@ int main (int argc, char *argv[])
 #endif
   int a = 0;
   int result;
+  struct simple_struct ss = { 10 };
   enum tag {one, two, three};
   enum tag t = one;
 
Index: testsuite/gdb.python/py-symtab.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symtab.exp,v
retrieving revision 1.8
diff -u -p -r1.8 py-symtab.exp
--- testsuite/gdb.python/py-symtab.exp	7 Feb 2012 19:42:27 -0000	1.8
+++ testsuite/gdb.python/py-symtab.exp	3 May 2012 06:47:38 -0000
@@ -49,6 +49,11 @@ gdb_continue_to_breakpoint "Block break 
 gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0
 gdb_py_test_silent_cmd "python sal = frame.find_sal()" "Get block" 0
 gdb_py_test_silent_cmd "python symtab = sal.symtab" "Get block" 0
+gdb_py_test_silent_cmd "python global_block = symtab.global_block()" "Get global block" 0
+gdb_py_test_silent_cmd "python static_block = symtab.static_block()" "Get static block" 0
+gdb_py_test_silent_cmd "python global_symbols = \[\]; static_symbols = \[\]" "Set up symbol name lists" 0
+gdb_py_test_silent_cmd "python for sym in global_block: global_symbols.append(sym.name)" "Get global symbol names" 0
+gdb_py_test_silent_cmd "python for sym in static_block: static_symbols.append(sym.name)" "Get static symbol names" 0
 
 # Test sal.
 gdb_test "python print sal.symtab" ".*gdb.python/py-symbol.c.*" "Test symtab"
@@ -61,6 +66,12 @@ gdb_test "python print symtab.filename" 
 gdb_test "python print symtab.objfile" "<gdb.Objfile object at ${hex}>" "Test symtab.objfile"
 gdb_test "python print symtab.fullname()" "testsuite/gdb.python/py-symbol.c.*" "Test symtab.fullname"
 gdb_test "python print symtab.is_valid()" "True" "Test symtab.is_valid()"
+gdb_test "python print \"qq\" in global_symbols" "True" "Test qq in global symbols"
+gdb_test "python print \"func\" in global_symbols" "True" "Test func in global symbols"
+gdb_test "python print \"main\" in global_symbols" "True" "Test main in global symbols"
+gdb_test "python print \"int\" in static_symbols" "True" "Test int in static symbols"
+gdb_test "python print \"char\" in static_symbols" "True" "Test char in static symbols"
+gdb_test "python print \"simple_struct\" in static_symbols" "True" "Test simple_struct in static symbols"
 
 # Test is_valid when the objfile is unloaded.  This must be the last
 # test as it unloads the object file in GDB.

FAILing new testcase for -fdebug-types-section [Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)]

[Jan Kratochvil]

Hi Siva,

by using -fdebug-types-section one gets:

runtest CC_FOR_TARGET="gcc -gdwarf-4 -fdebug-types-section -g0" CXX_FOR_TARGET="g++ -gdwarf-4 -fdebug-types-section -g0" gdb.python/py-symtab.exp

 python print "simple_struct" in static_symbols
-True
-(gdb) PASS: gdb.python/py-symtab.exp: Test simple_struct in static symbols
+False
+(gdb) FAIL: gdb.python/py-symtab.exp: Test simple_struct in static symbols


Thanks,
Jan

Re: FAILing new testcase for -fdebug-types-section [Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)]

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Fri, May 4, 2012 at 11:34 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi Siva,
>
> by using -fdebug-types-section one gets:
>
> runtest CC_FOR_TARGET="gcc -gdwarf-4 -fdebug-types-section -g0" CXX_FOR_TARGET="g++ -gdwarf-4 -fdebug-types-section -g0" gdb.python/py-symtab.exp
>
>  python print "simple_struct" in static_symbols
> -True
> -(gdb) PASS: gdb.python/py-symtab.exp: Test simple_struct in static symbols
> +False
> +(gdb) FAIL: gdb.python/py-symtab.exp: Test simple_struct in static symbols

I think the attached patch should eliminate this failure.  Can you
also test on your side to eliminate GCC version differences (I do not
think it matters, but I want to double check)?  All that I did is to
remove 'simple_struct' and its test, and add a static function and a
test for it.

testsuite:
2012-05-05  Siva Chandra Reddy  <sivachandra@gmail.com>

        * py-symbol.c (simple_struct): Remove
        (static_func): New static func
        * py-symtab.exp: Remove test to test presence of 'simple_struct'
        in STATIC_BLOCK, add test to test presence of 'static_func' in
        STATIC_BLOCK.

Thanks,
Siva Chandra

[-- Attachment #2: test_fix_patch_v1.txt --]
[-- Type: text/plain, Size: 1794 bytes --]

Index: py-symbol.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symbol.c,v
retrieving revision 1.6
diff -u -p -r1.6 py-symbol.c
--- py-symbol.c	3 May 2012 07:07:26 -0000	1.6
+++ py-symbol.c	5 May 2012 06:36:41 -0000
@@ -44,10 +44,11 @@ int func (int arg)
   return arg; /* Block break here.  */
 }
 
-struct simple_struct
+static int
+static_func (int a, int b)
 {
-  int a;
-};
+  return a + b;
+}
 
 int main (int argc, char *argv[])
 {
@@ -55,12 +56,12 @@ int main (int argc, char *argv[])
   SimpleClass sclass;
 #endif
   int a = 0;
-  int result;
-  struct simple_struct ss = { 10 };
+  int result, result1;
   enum tag {one, two, three};
   enum tag t = one;
 
   result = func (42);
+  result1 = static_func (5, 10);
 
 #ifdef __cplusplus
   sclass.seti (42);
Index: py-symtab.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/py-symtab.exp,v
retrieving revision 1.9
diff -u -p -r1.9 py-symtab.exp
--- py-symtab.exp	3 May 2012 07:07:26 -0000	1.9
+++ py-symtab.exp	5 May 2012 06:36:41 -0000
@@ -71,7 +71,7 @@ gdb_test "python print \"func\" in globa
 gdb_test "python print \"main\" in global_symbols" "True" "Test main in global symbols"
 gdb_test "python print \"int\" in static_symbols" "True" "Test int in static symbols"
 gdb_test "python print \"char\" in static_symbols" "True" "Test char in static symbols"
-gdb_test "python print \"simple_struct\" in static_symbols" "True" "Test simple_struct in static symbols"
+gdb_test "python print \"static_func\" in static_symbols" "True" "Test static_func in static symbols"
 
 # Test is_valid when the objfile is unloaded.  This must be the last
 # test as it unloads the object file in GDB.

Re: FAILing new testcase for -fdebug-types-section [Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)]

[Jan Kratochvil]

On Sat, 05 May 2012 09:01:36 +0200, Siva Chandra wrote:
> I think the attached patch should eliminate this failure.  Can you
> also test on your side to eliminate GCC version differences (I do not
> think it matters, but I want to double check)?  All that I did is to
> remove 'simple_struct' and its test, and add a static function and a
> test for it.

Isn't it just hiding some real DWARF GCC or GDB bug?

I do not say your code is wrong, your patch may have just discovered a bug
elsewhere but I did not have time to investigate it more so I though you may
provide the explanation where the real bug is.


Thanks,
Jan

Re: FAILing new testcase for -fdebug-types-section [Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)]

[Siva Chandra]

On Sat, May 5, 2012 at 12:34 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Isn't it just hiding some real DWARF GCC or GDB bug?
>
> I do not say your code is wrong, your patch may have just discovered a bug
> elsewhere but I did not have time to investigate it more so I though you may
> provide the explanation where the real bug is.

I did notice this issue and did mention the difference during the
discussion about this patch. Essentially, I see a difference in
interpreting user defined types as global in C++ and as static in C.
I was planning to raise a question on this on gdb@.  If you feel there
is no urgency in eliminating the failure you are seeing, I will dig a
little more into this and start a discussion in a few days.

Thanks,
Siva Chandra

Re: FAILing new testcase for -fdebug-types-section [Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)]

[Jan Kratochvil]

On Sat, 05 May 2012 09:10:44 +0200, Siva Chandra wrote:
> If you feel there
> is no urgency in eliminating the failure you are seeing, I will dig a
> little more into this and start a discussion in a few days.

A patch should go in only if it is understood why.


Thanks,
Jan

[patch KFAIL] Re: FAILing new testcase for -fdebug-types-section (PR symtab/14148)

[Jan Kratochvil]

On Sat, 05 May 2012 09:13:06 +0200, Jan Kratochvil wrote:
> On Sat, 05 May 2012 09:10:44 +0200, Siva Chandra wrote:
> > If you feel there
> > is no urgency in eliminating the failure you are seeing, I will dig a
> > little more into this and start a discussion in a few days.
> 
> A patch should go in only if it is understood why.

I have filed:
	-fdebug-types-section regresses ststic scope of types
	http://sourceware.org/bugzilla/show_bug.cgi?id=14148

As I do not intend to fix it proposing KFAIL below.  The fix needs to start
tracking types signatures during psymtab building to look up the type name
during psymtab-scanning DW_TAG_variable.


Thanks,
Jan


2012-05-23  Siva Chandra Reddy  <sivachandra@gmail.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>

	Setup KFAIL symtab/14148.
	* py-symbol.c (static_func): New static function.
	(main): New variable result1, call static_func.
	* py-symtab.exp (Test static_func in static symbols): New test.
	(Test simple_struct in static symbols): KFAIL it with .debug_types.

diff --git a/gdb/testsuite/gdb.python/py-symbol.c b/gdb/testsuite/gdb.python/py-symbol.c
index 8c6cdb1..92eb7cd 100644
--- a/gdb/testsuite/gdb.python/py-symbol.c
+++ b/gdb/testsuite/gdb.python/py-symbol.c
@@ -49,18 +49,25 @@ struct simple_struct
   int a;
 };
 
+static int
+static_func (int a, int b)
+{
+  return a + b;
+}
+
 int main (int argc, char *argv[])
 {
 #ifdef __cplusplus
   SimpleClass sclass;
 #endif
   int a = 0;
-  int result;
+  int result, result1;
   struct simple_struct ss = { 10 };
   enum tag {one, two, three};
   enum tag t = one;
 
   result = func (42);
+  result1 = static_func (5, 10);
 
 #ifdef __cplusplus
   sclass.seti (42);
diff --git a/gdb/testsuite/gdb.python/py-symtab.exp b/gdb/testsuite/gdb.python/py-symtab.exp
index 6eec611..689b42a 100644
--- a/gdb/testsuite/gdb.python/py-symtab.exp
+++ b/gdb/testsuite/gdb.python/py-symtab.exp
@@ -71,6 +71,17 @@ gdb_test "python print \"func\" in global_symbols" "True" "Test func in global s
 gdb_test "python print \"main\" in global_symbols" "True" "Test main in global symbols"
 gdb_test "python print \"int\" in static_symbols" "True" "Test int in static symbols"
 gdb_test "python print \"char\" in static_symbols" "True" "Test char in static symbols"
+gdb_test "python print \"static_func\" in static_symbols" "True" "Test static_func in static symbols"
+
+set readelf_program [transform readelf]
+set command "exec $readelf_program -WS $binfile"
+verbose -log "command is $command"
+set result [catch $command output]
+verbose -log "result is $result"
+verbose -log "output is $output"
+if {$result == 0 && [regexp { \.debug_types } $output]} {
+    setup_kfail symtab/14148 "*-*-*"
+}
 gdb_test "python print \"simple_struct\" in static_symbols" "True" "Test simple_struct in static symbols"
 
 # Test is_valid when the objfile is unloaded.  This must be the last

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> 2012-04-18  Siva Chandra Reddy  <sivachandra@google.com>
Siva>        Add two new methods global_block and static_block to gdb.Symtab
Siva>        objects.
Siva>        * NEWS (Python scripting): Add entry about the new methods.
Siva>        * python/py-symtab.c (stpy_global_block): New function which
Siva>        implements the gdb.Symtab.global_block() method.
Siva>        (stpy_static_block): New function which implements the
Siva>        gdb.Symtab.static_block() method.
Siva>        (symtab_object_methods): Add entries for the two new methods.

Siva> Testsuite:
Siva> 2012-04-18  Siva Chandra Reddy  <sivachandra@google.com>

Siva>        * gdb.python/py-symbol.exp: Add tests to test the new methods
Siva>        gdb.Symtab.global_block() and gdb.Symtab.static_block().
Siva>        * gdb.python/py-symbol.c: Add new struct to help test
Siva>        gdb.Symtab.static_block().

Thanks, these parts are ok.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Eli Zaretskii]

> Date: Wed, 18 Apr 2012 14:19:07 +0530
> From: Siva Chandra <sivachandra@google.com>
> Cc: gdb-patches@sourceware.org
> 
> Thanks Eli, for taking a look.  I have modified according to your
> comments.  I would like you to take a look at the doc changes again
> since the suggestion wasn't objective for the second change.

I'm happy now, thanks.  I understand that the issue is still being
debated, and probably some more documentation changes will follow.

Thanks.

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> The attached patch is a result of discussions here:
Siva>     http://sourceware.org/ml/gdb-patches/2012-04/msg00226.html
Siva> and here:
Siva>     http://sourceware.org/ml/gdb-patches/2012-04/msg00302.html

Thanks.

It looks pretty good, just a little nit.

Siva> +  block = symtab->blockvector->block[GLOBAL_BLOCK];

Siva> +  block = symtab->blockvector->block[STATIC_BLOCK];

These two spots should use the BLOCKVECTOR accessor macro.

Ok with that change.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Siva> +  block = symtab->blockvector->block[GLOBAL_BLOCK];

Siva> +  block = symtab->blockvector->block[STATIC_BLOCK];

Tom> These two spots should use the BLOCKVECTOR accessor macro.

I forgot that we also have blockvector accessors.
So, could you change these to use BLOCKVECTOR_BLOCK as well?
Thanks.

Tom

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Siva Chandra]

Siva> +  block = symtab->blockvector->block[GLOBAL_BLOCK];

Siva> +  block = symtab->blockvector->block[STATIC_BLOCK];

Tom> These two spots should use the BLOCKVECTOR accessor macro.

Tom> I forgot that we also have blockvector accessors.
Tom> So, could you change these to use BLOCKVECTOR_BLOCK as well?

I have already done this in the updated patch I have sent today:
http://sourceware.org/ml/gdb-patches/2012-04/msg00543.html

Thanks,
Siva Chandra

Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> I have already done this in the updated patch I have sent today:
Siva> http://sourceware.org/ml/gdb-patches/2012-04/msg00543.html

Thanks -- somehow I missed it, I sent a response now.

Tom