From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9480 invoked by alias); 5 Sep 2012 18:54:13 -0000 Received: (qmail 9469 invoked by uid 22791); 5 Sep 2012 18:54:12 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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; Wed, 05 Sep 2012 18:53:54 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q85Irr3q019997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2012 14:53:53 -0400 Received: from host2.jankratochvil.net (ovpn-116-22.ams2.redhat.com [10.36.116.22]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q85IrnEh003566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 14:53:52 -0400 Date: Wed, 05 Sep 2012 18:54:00 -0000 From: Jan Kratochvil To: Andrew Burgess Cc: "gdb-patches@sourceware.org" Subject: Re: PATCH: error reading variable: value has been optimized out Message-ID: <20120905185349.GA13463@host2.jankratochvil.net> References: <50376F3B.1080407@broadcom.com> <20120826171840.GA21205@host2.jankratochvil.net> <504092C0.2000602@broadcom.com> <20120903151626.GB16315@host2.jankratochvil.net> <50463305.2080802@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50463305.2080802@broadcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-09/txt/msg00042.txt.bz2 On Tue, 04 Sep 2012 18:57:41 +0200, Andrew Burgess wrote: > On 03/09/2012 4:16 PM, Jan Kratochvil wrote: > > ABI registers order: rdi rsi rdx rcx r8 r9 > > ==amd64_dummy_call_integer_regs > > You're correct that what I originally wrote was not correct, but I think the > register ordering used for what was test2, which is the > extend-into-next-register behaviour, is actually just using the gdb register > number, so this would be from the enum amd64_regnum. In my text above I was only following the ABI standard http://www.x86-64.org/documentation/abi.pdf specifically: 2. If the class is INTEGER, the next available register of the sequence %rdi, %rsi, %rdx, %rcx, %r8 and %r9 is used13 . IIUC this does not mean this hack of register numbers flowing should be used, it just specifies which registers should be put in DWARF for DW_OP_piece. In the case the hack of register numbers flowing is used: For i386 there is: i386_register_to_value -> i386_next_regnum so i386 does not follow GDB numbering but its own one. During my testcase GDB (correctly for GCC) composed HIGH(%edx==gdb reg. #2) | LOW(%eax==gdb reg. #0). as i386_next_regnum (%eax==gdb reg. #0) == %edx==gdb reg. #2. For amd64 the target code does not do anything specific so it is processed in read_frame_register_value and it really follows the GDB registers numbering. But that seems wrong to me as it violates the ABI specification above. Still it is not being used for anything in real world I think. An assertion there does not trigger on GDB testsuite at all. It would trigger on the AVR target it was written for [RFA/RFC] Restore old handling of multi-register variables http://sourceware.org/ml/gdb-patches/2011-10/msg00052.html but I think that should have been written only to avr-tdep.c with some AVR registers numbering on mind. I was unable to produce any such DWARF output (using register numbers flowing) from any i386/x86_64 GCC compiler here, like FSF 3.4.6, Red Hat 4.1 or FSF 4.4. So I do not think it is of any much concern how multi-register values behave in read_frame_register_value, except for that AVR compatibility. It is also not exploited by your 'bad-bt' testcase. It is exploited by 'struct_param_single_reg_loc' from your new testcase but specifying gdb numbers of registers there is rather a compatibility with current - assumed buggy - GDB behavior. > Any more feedback, or is this ok to commit ? I am fine with that stating there like: This gdb register numbers usage exposed to external DWARF data is more a GDB bug and it should be move to target dependent code (such as AVR) as a workaround of existing broken DWARF. Best to keep it here for a week for comments before commit. Thanks, Jan