From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5637 invoked by alias); 8 Aug 2010 15:01:18 -0000 Received: (qmail 5521 invoked by uid 22791); 8 Aug 2010 15:01:18 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.17.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 08 Aug 2010 15:01:12 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.1/8.13.1) with ESMTP id o78F19gw017687 for ; Sun, 8 Aug 2010 15:01:09 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o78F19Z11802242 for ; Sun, 8 Aug 2010 17:01:09 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o78F197q011594 for ; Sun, 8 Aug 2010 17:01:09 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o78F18sq011585; Sun, 8 Aug 2010 17:01:08 +0200 Message-Id: <201008081501.o78F18sq011585@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 08 Aug 2010 17:01:08 +0200 Subject: Re: [patch] smart pointer support To: tromey@redhat.com (Tom Tromey) Date: Sun, 08 Aug 2010 15:01:00 -0000 From: "Ulrich Weigand" Cc: swagiaal@redhat.com (sami wagiaalla), gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at Aug 06, 2010 11:29:44 AM 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-08/txt/msg00096.txt.bz2 Tom Tromey wrote: > Along these lines, I'm curious to know why value_must_coerce_to_target > returns 0 for TYPE_CODE_STRUCT. Maybe that is just an oversight? > Perhaps it should also check for lval_internalvar_component? Well, I guess this is because the value-coerce-to-target mechanism was introduced by Dan for a specific purpose, that is to allow lazy handling of GDB-internally generated literal values (in particular string constants). It was never intended to handle pushing arbitrary non-lvalues, like those generated from inferior calls (or arbitray value arithmetic) to the target. Now maybe this could be extended to do so; but it seems we'd have to carefully think about exactly when we want this to happen. For example, if you have a variable residing in a register, you currently cannot take its address in GDB. If value_coerce_to_target were to blindly push *everything* to the target, this would succeed, and you'd have a pointer to a malloc'ed location holding a copy of the register value -- which is presumably not what you intended ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com