headers
Jan Kratochvil | 1 Mar 2009 15:32
Picon
Favicon

[python] [commit] Workaroud Fedora 10 gcc-4.3.2-7 false warning.

commit 3d0c4bcb05d5112ca43433e3c0fd5185c9ea945e

	* python/python-frame.c (frapy_read_var_value): Initialize `var'.
---
 gdb/python/python-frame.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gdb/python/python-frame.c b/gdb/python/python-frame.c
index ef1c178..1f152b8 100644
--- a/gdb/python/python-frame.c
+++ b/gdb/python/python-frame.c
 <at>  <at>  -401,7 +401,7  <at>  <at>  frapy_read_var_value (PyObject *self, PyObject *args)
 {
   struct frame_info *frame;
   PyObject *sym_obj;
-  struct symbol *var;
+  struct symbol *var = NULL;	/* gcc-4.3.2 false warning.  */
   struct value *val = NULL;
   volatile struct gdb_exception except;

--

-- 
1.6.0.6
Permalink | Reply | 0 comments |
headers
Jan Kratochvil | 1 Mar 2009 17:19
Picon
Favicon

[keiths-expr-cumulative] Regressions [Re: New branch for Fedora 11 merges]

On Fri, 27 Feb 2009 23:03:26 +0100, Sami Wagiaalla wrote:
> Sami Wagiaalla wrote:
>> I introduced this problem earlier when i was trying to resolve a  
>> conflict that I had with a patch of Jan's.  
>> 1de38657622396795ce681e64b03fb74e81e6c3d vs  
>> 60eb8684d0d85d0884aca7a2f013e5eb16a51d47
>>
>> I'll check in a fix for this. The issue is that sometimes a function 
>> Die might now have high/low pc tags but it has an abstract origin tag  
>> pointing to useful namespace information.
>
> I have check in a fix for this.

[archer-keiths-expr-cumulative] 3513c57475d20e65ac2fb2be097227011c4b8b5a

It still has a lot of regressions (tried archer-keiths-expr-cumulative) like:
	info function operator\*(^M
	memory clobbered past end of allocated block^M
	FAIL: gdb.cp/cplusfuncs.exp: info function for "operator%(" (timeout)
(at least on F10.x86_64 using mcheck: LDFLAGS="-lmcheck" ./configure...).

Possible quick fix is attached (not checked-in) - my code moved into
explore_abstract_origin() needs to know (the `die_children' count is only read)
the number of children DIEs - to allocate appropriately sized array.

Unfortunately even after this attached fix the branch is FAILing on:
+FAIL: gdb.cp/namespace-using.exp: print _a
+FAIL: gdb.cp/namespace-using.exp: print x

* Every test name should be unique - this is the reason the names exist.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jan Kratochvil | 1 Mar 2009 20:29
Picon
Favicon

[python] Packacking - Python scripts directories

Hi Tom,

while rpm-packaging [python] branch into Archer I found there is IMO incorrect
placement of the Python scripts.

https://fedoraproject.org/wiki/Packaging/Python
describes it should be placed in
  /usr/lib/python2.5/site-packages/gdb
Not /usr/lib64/python2.5 on 64-bit as these files are arch-independent.
I would also place it in /usr/share as arch-independent but this is the way
described both by the Fedora guidelines and seen at all the (tried) Fedora
existing packages providing 3rd party modules for Python (like libxml2-python).

--with-gdb-datadir should probably remain present as it is in use by
[archer-sergio-catch-syscall].

--with-gdb-pythondir and `maint set gdb_pythondir' should be new
(IMO the GDB style would be more like `maint set python-directory'.)

The configure.ac code trying 2.4/2.5/2.6 directories to find the include
directory can be IMO replaced by:
  python -c "from distutils.sysconfig import get_python_inc; print get_python_inc()"
  (which prints `/usr/include/python2.5')

The target directory for Python scripts should be:
  python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
  (which prints `/usr/lib/python2.5/site-packages')

As gdb.pythonlibdir is now the same as the system Python modules directory it
can be IMO removed.  (I do not understand why `import' with some
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thiago Jung Bauermann | 2 Mar 2009 14:27
Picon

[python] Verify if given var name exists, and plug memory leak.

Hi,

frapy_read_var_frame was leaking the var_name buffer. Also, it didn't
check the return value of lookup_symbol.

Also, update testcase to test functions and methods which weren't being
tested.

Committed.

gdb/
	* python/python-frame.c (frapy_read_var_value): Don't leak variable
	name, and verify if variable with given name exists.

gdb/testsuite/
	* gdb.python/python-frame.exp: Add tests for Frame.read_var_value,
	gdb.newest_frame, gdb.selected_frame and
	gdb.frame_unwind_stop_reason_string.

diff --git a/gdb/python/python-frame.c b/gdb/python/python-frame.c
index 1f152b8..131aad1 100644
--- a/gdb/python/python-frame.c
+++ b/gdb/python/python-frame.c
 <at>  <at>  -413,20 +413,32  <at>  <at>  frapy_read_var_value (PyObject *self, PyObject *args)
   else if (gdbpy_is_string (sym_obj))
     {
       char *var_name;
-      struct block *block;
+      struct block *block = NULL;
+      struct cleanup *cleanup;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thiago Jung Bauermann | 2 Mar 2009 14:28
Picon

[python] Documentation fixes for gdb.Frame.

Hi,

Just committed this.

gdb/
	* python/python-frame.c (gdbpy_initialize_frames): Mark comment as a
	note instead of a FIXME.

gdb/doc/
	* gdb.texinfo (Basic Python): Document `gdb.solib_address'.
	(Frames In Python): Document `Frame.unwind_stop_reason' and
	`Frame.block'.  Reword documentation for `Frame.read_var_value'.
---
 gdb/doc/gdb.texinfo       |   20 ++++++++++++++++++--
 gdb/python/python-frame.c |    2 +-
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index d055353..fef4680 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
 <at>  <at>  -18305,6 +18305,11  <at>  <at>  which is typically four bytes.   <at> var{max_count} is the highest number of matches
 to search for.
  <at> end defun

+ <at> findex gdb.solib_address
+ <at> defun solib_address  <at> var{address}
+Return the name of the shared library holding the given address, or None.
+ <at> end defun
+
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Tromey | 2 Mar 2009 16:38
Picon
Favicon

bugzilla

I finally remembered to set up bugzilla for archer.

All this really means is that I've added an "archer" version to the
gdb bugzilla.  If you want to file a bug against some archer branch,
use this as the version.  I suppose we ought to mention the exact
branch in the text somewhere.

Tom
Permalink | Reply | 0 comments |
headers
Sami Wagiaalla | 2 Mar 2009 16:39
Picon
Favicon

Re: [keiths-expr-cumulative] Regressions [Re: New branch for Fedora 11 merges]

Jan Kratochvil wrote:
> On Fri, 27 Feb 2009 23:03:26 +0100, Sami Wagiaalla wrote:
>> Sami Wagiaalla wrote:
>>> I introduced this problem earlier when i was trying to resolve a  
>>> conflict that I had with a patch of Jan's.  
>>> 1de38657622396795ce681e64b03fb74e81e6c3d vs  
>>> 60eb8684d0d85d0884aca7a2f013e5eb16a51d47
>>>
>>> I'll check in a fix for this. The issue is that sometimes a function 
>>> Die might now have high/low pc tags but it has an abstract origin tag  
>>> pointing to useful namespace information.
>> I have check in a fix for this.
> 
> [archer-keiths-expr-cumulative] 3513c57475d20e65ac2fb2be097227011c4b8b5a
> 
> 
> It still has a lot of regressions (tried archer-keiths-expr-cumulative) like:
> 	info function operator\*(^M
> 	memory clobbered past end of allocated block^M
> 	FAIL: gdb.cp/cplusfuncs.exp: info function for "operator%(" (timeout)
> (at least on F10.x86_64 using mcheck: LDFLAGS="-lmcheck" ./configure...).
> 
> Possible quick fix is attached (not checked-in) - my code moved into
> explore_abstract_origin() needs to know (the `die_children' count is only read)
> the number of children DIEs - to allocate appropriately sized array.
> 

I have committed your patch. Thanks.

>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jan Kratochvil | 2 Mar 2009 16:50
Picon
Favicon

Re: [keiths-expr-cumulative] Regressions

On Mon, 02 Mar 2009 16:39:17 +0100, Sami Wagiaalla wrote:
>> Unfortunately even after this attached fix the branch is FAILing on:
>> +FAIL: gdb.cp/namespace-using.exp: print _a
>> +FAIL: gdb.cp/namespace-using.exp: print x
>
> Are these the only regressions left ?

There is also that `constructor breakpoint' FAIL although assuming it is not
from you.  And feel free to run the testsuite yourself and compare the gdb.sum
files from unpatched GDB.  :-)

> Thanks for the pointers. I have made the changes and committed the patch.

c7c96c12054b0089c813555d72c60e8cdaa56946 looks OK to me, thanks.

> I will update if there are no regressions now.

I already had to update it in archer-jankratochvil-expr.  Just there was some
conflict in dwarf2_build_psymtabs_hard due to
e56b9f4bab7f78c2749bc115cc2aa5bdd7375e8c which I resolved there wrong
regarding CU PC ranges determination.  IMO that
e56b9f4bab7f78c2749bc115cc2aa5bdd7375e8c should be reverted if possible.

Regards,
Jan
Permalink | Reply | 2 comments |
headers
Tom Tromey | 2 Mar 2009 17:02
Picon
Favicon

Re: [keiths-expr-cumulative] Regressions

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@...> writes:

Jan> And feel free to run the testsuite yourself and compare the
Jan> gdb.sum files from unpatched GDB.  :-)

If anybody is interested, you can easily use the auto-tester on the
compile farm to regtest two revisions.

Tom
Permalink | Reply | 0 comments |
headers
Tom Tromey | 2 Mar 2009 17:05
Picon
Favicon

Re: [python] Make gdb.Command.__init__ accept keyword arguments.

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@...> writes:

Thiago> gdb/doc/
Thiago> 	* gdb.texinfo (Commands In Python): Adjust argument names of
Thiago> 	gdb.Command.__init__ to what the function accepts as keywords.

I think we should somehow make it clear that the argument names in the
documentation are in fact keywords.  I don't have a super suggestion
for how to do this though.

Tom
Permalink | Reply | 0 comments |

Gmane