From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20939 invoked by alias); 30 Apr 2010 16:19:45 -0000 Received: (qmail 20920 invoked by uid 22791); 30 Apr 2010 16:19:43 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.156) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Apr 2010 16:19:38 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3UGJYJM070130 for ; Fri, 30 Apr 2010 18:19:35 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o3UGJYjg084484 for ; Fri, 30 Apr 2010 18:19:34 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3UGJWYU085437 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 30 Apr 2010 18:19:34 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: Subject: [RFC] examine for TYPE_CODE_REF in pascal language PR 11349 Date: Fri, 30 Apr 2010 16:19:00 -0000 Message-ID: <002a01cae880$ef397ae0$cdac70a0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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-04/txt/msg00998.txt.bz2 Trying to fix bug report PR 11349, http://sourceware.org/bugzilla/show_bug.cgi?id=11349 I finally found this: -inside x_command, a TYPE_CODE_REF generates a call to value_ind, but this generates possibly several dereferencing if the target type is also a pointer. In Free Pascal, with dwarf debug format, variables passed as 'var' are considered as TYPE_CODE_REF. if the variable itself is an ansistring, this type is simply a type pointing to a CHAR. the function DOIT has one parameter 'by var' called S of type ANSISTRING. If I try to examine as a string this variable (gdb) x /s S as S type is a TYPE_CODE_REF, value_ind is called, but this dereferences the type twice so that we end up with a single CHAR value: hence the error 0x74:
If I replace value_ind by coerce_ref, everything works as I want it for pascal, but I was wandering if this is not also what other languages would expect. (gdb) x /s S 0x408094 <$TEST_GDB_BUG_11349$_Ld3>: 'test' I do not know what is the expectation for C language here, and I don't even know how to generate code that has variables of type TYPE_CODE_REF from C source. Should this change be extended to other languages or to all languages? Pierre Muller Pascal language support maintainer for GDB 2010-04-30 Pierre Muller * printcmd.c (x_command): Only dereference once implicitly for TYPE_CODE_REF type for pascal language. Index: src/gdb/printcmd.c =================================================================== RCS file: /cvs/src/src/gdb/printcmd.c,v retrieving revision 1.176 diff -u -p -r1.176 printcmd.c --- src/gdb/printcmd.c 22 Apr 2010 23:15:41 -0000 1.176 +++ src/gdb/printcmd.c 30 Apr 2010 13:12:45 -0000 @@ -1420,7 +1420,12 @@ x_command (char *exp, int from_tty) old_chain = make_cleanup (free_current_contents, &expr); val = evaluate_expression (expr); if (TYPE_CODE (value_type (val)) == TYPE_CODE_REF) - val = value_ind (val); + { + if (current_language->la_language == language_pascal) + val = coerce_ref (val); + else + val = value_ind (val); + } /* In rvalue contexts, such as this, functions are coerced into pointers to functions. This makes "x/i main" work. */ if (/* last_format == 'i' && */