From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23092 invoked by alias); 30 Mar 2010 14:46:32 -0000 Received: (qmail 23082 invoked by uid 22791); 30 Mar 2010 14:46:32 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Mar 2010 14:46:27 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2UEkPZC007417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Mar 2010 10:46:25 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2UEkOnU026462 for ; Tue, 30 Mar 2010 10:46:25 -0400 Message-ID: <4BB20EC0.10500@redhat.com> Date: Tue, 30 Mar 2010 14:46:00 -0000 From: Phil Muldoon User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 MIME-Version: 1.0 To: gdb-patches ml Subject: [patch] PR 11417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg01045.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11417 The OP of that bug posts an interesting issue. If the address of a value in the inferior is 0x0, should the user still be able to create a Python lazy string from that value? My first reaction was no -- purely for the reason that anything with an address of 0x0 can ever be lazily fetched. But the problem here is compatibility with Value.string, and the enormous pain in the neck it would be to check for NULL on every value before a lazy string could be created. Maybe we should just handle lazy strings with no address? And when printing occurs print nothing (or in this case, with GDB, print ""). I created a patch to do that and have attached it. While this is technically incorrect, I think it will make life a little easier. One of the side effects of this change is that if you want to convert a lazy string back into a value, GDB will raise an exception with address 0x0. I gated that one side effect by raising an exception. Tested on x86_64 with no regressions What do you think? Cheers, Phil -- 2010-03-30 Phil Muldoon PR python/11417 * python/py-lazy-string.c (stpy_convert_to_value): Check for a NULL address. (gdbpy_create_lazy_string_object): Allow strings with a NULL address. -- diff --git a/gdb/python/py-lazy-string.c b/gdb/python/py-lazy-string.c index 8309527..a7a4046 100644 --- a/gdb/python/py-lazy-string.c +++ b/gdb/python/py-lazy-string.c @@ -94,6 +94,13 @@ stpy_convert_to_value (PyObject *self, PyObject *args) lazy_string_object *self_string = (lazy_string_object *) self; struct value *val; + if (self_string->address == 0) + { + PyErr_SetString (PyExc_MemoryError, + "Cannot create a value from NULL"); + return NULL; + } + val = value_at_lazy (self_string->type, self_string->address); return value_to_value_object (val); } @@ -111,13 +118,6 @@ gdbpy_create_lazy_string_object (CORE_ADDR address, long length, { lazy_string_object *str_obj = NULL; - if (address == 0) - { - PyErr_SetString (PyExc_MemoryError, - "Cannot create a lazy string from a GDB-side string."); - return NULL; - } - if (!type) { PyErr_SetString (PyExc_RuntimeError,