From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17248 invoked by alias); 3 Sep 2009 22:17:44 -0000 Received: (qmail 17236 invoked by uid 22791); 3 Sep 2009 22:17:44 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 22:17:37 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n83MHYUN020760 for ; Thu, 3 Sep 2009 15:17:34 -0700 Received: from ywh17 (ywh17.prod.google.com [10.192.8.17]) by wpaz13.hot.corp.google.com with ESMTP id n83MHKLq026620 for ; Thu, 3 Sep 2009 15:17:32 -0700 Received: by ywh17 with SMTP id 17so582642ywh.3 for ; Thu, 03 Sep 2009 15:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.130.38 with SMTP id c38mr1347004ybd.213.1252016252029; Thu, 03 Sep 2009 15:17:32 -0700 (PDT) In-Reply-To: <200909032303.56901.pedro@codesourcery.com> References: <200909032303.56901.pedro@codesourcery.com> Date: Thu, 03 Sep 2009 22:17:00 -0000 Message-ID: Subject: Re: store.exp failure on i686-linux with newer gcc's From: Doug Evans To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00061.txt.bz2 On Thu, Sep 3, 2009 at 3:03 PM, Pedro Alves wrote: > On Thursday 03 September 2009 22:50:13, Doug Evans wrote: > >> Newer gcc's can store a 64 bit int in non-contiguous registers and use >> DW_OP_piece to mark each piece. >> >> value->lval is set to not_lval and value_assign doesn't like that so >> gdb refuses to set the variable with "Left operand of assignment is >> not an lvalue." >> >> It seems like we need to not mark the value as not_lval and teach the >> relevant pieces how to handle such values. >> Anyone thought about how they want this done? > > Nathan Froyd has a patch for this, using the lval_computed > machinery. Good thing I checked first. :-) Thanks. What's the status? [if I may ask - no rush, just curious]