From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8679 invoked by alias); 15 May 2017 16:35:41 -0000 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 Received: (qmail 8588 invoked by uid 89); 15 May 2017 16:35:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=occupy X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 May 2017 16:35:37 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4FGXmpM012191 for ; Mon, 15 May 2017 12:35:38 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2affj5s7s4-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 15 May 2017 12:35:38 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 15 May 2017 17:35:36 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 15 May 2017 17:35:34 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4FGZYO420119824; Mon, 15 May 2017 16:35:34 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 08F24AE056; Mon, 15 May 2017 17:33:46 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDFB1AE058; Mon, 15 May 2017 17:33:45 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.109]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 15 May 2017 17:33:45 +0100 (BST) From: Andreas Arnez To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 03/19] PR gdb/21226: Take DWARF stack value pieces from LSB end References: <1494352015-10465-1-git-send-email-arnez@linux.vnet.ibm.com> <1494352015-10465-4-git-send-email-arnez@linux.vnet.ibm.com> <86wp9icvnn.fsf@gmail.com> Date: Mon, 15 May 2017 16:35:00 -0000 In-Reply-To: <86wp9icvnn.fsf@gmail.com> (Yao Qi's message of "Mon, 15 May 2017 10:32:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17051516-0040-0000-0000-0000038B526A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051516-0041-0000-0000-00002561F461 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-15_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705150161 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00321.txt.bz2 On Mon, May 15 2017, Yao Qi wrote: > Andreas Arnez writes: > >> * DW_OP_piece shall take the piece from the LSB end as well; >> > > My understanding is that this is true for a given arch or ABI. Well, if a DWARF stack value is of some integral type, the LSB end is well-defined, independently from the ABI. I don't know whether any DWARF consumer emits something like a 3-byte DW_OP_piece of an 8-byte floating-point stack value, and what it would mean by that. My best guess is that it would refer to the same 3 bytes of the stack value's in-memory representation as if the value *was* of integral type. Or do you refer to the DWARF definition of DW_OP_piece? -- "If the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI." Unfortunately nothing is said about pieces from something else but registers; thus I phrased my assumption above. I can't verify the assumption for all DWARF producers, but I'm pretty sure that it holds for GCC and LLVM. > This change will affect other big-endian architectures, like mips. Right, the change affects (hopefully fixes) all big-endian architectures, because stack value pieces were taken from the lowest-addressed end so far, where they should have been taken from the LSB end instead. These two placement rules happen to be the same on little-endian architectures, which are consequently unaffected by the change. > >> @@ -1866,26 +1870,30 @@ read_pieced_value (struct value *v) >> p->v.mem.in_stack_memory, >> p->v.mem.addr + source_offset, >> buffer.data (), this_size); >> + copy_bitwise (contents, dest_offset_bits, >> + intermediate_buffer, source_offset_bits % 8, >> + this_size_bits, bits_big_endian); >> break; >> >> case DWARF_VALUE_STACK: >> { >> - size_t n = this_size; >> + struct objfile *objfile = dwarf2_per_cu_objfile (c->per_cu); >> + struct gdbarch *objfile_gdbarch = get_objfile_arch (objfile); >> + ULONGEST stack_value_size_bits >> + = 8 * TYPE_LENGTH (value_type (p->v.value)); >> >> - if (n > c->addr_size - source_offset) >> - n = (c->addr_size >= source_offset >> - ? c->addr_size - source_offset >> - : 0); >> - if (n == 0) >> - { >> - /* Nothing. */ >> - } >> - else >> - { >> - const gdb_byte *val_bytes = value_contents_all (p->v.value); >> + /* Use zeroes if piece reaches beyond stack value. */ >> + if (p->size > stack_value_size_bits) >> + break; > > Does this indicate something wrong in DWARF producer? Does GDB need to > emit a complaint? I don't know any DWARF producer that would emit such a DWARF piece. Whether it should be considered valid or not is unclear. Probably not. But if we emit a complaint for such a piece, then all pieces will become unusable just because GDB can't deal with that one piece. Before the change, no complaint was emitted either; not sure if the author had another reason for that. -- Andreas