From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43023 invoked by alias); 10 Mar 2017 17:43:26 -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 43001 invoked by uid 89); 10 Mar 2017 17:43:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=states, H*x:version X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Mar 2017 17:43:24 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2AHcr4l005700 for ; Fri, 10 Mar 2017 12:43:23 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2938svxgkr-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Mar 2017 12:43:23 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Mar 2017 17:43:21 -0000 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; Fri, 10 Mar 2017 17:43:18 -0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v2AHhIIk8782302; Fri, 10 Mar 2017 17:43:18 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A41884C040; Fri, 10 Mar 2017 17:43:07 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 846204C046; Fri, 10 Mar 2017 17:43:07 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.164.174.223]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 10 Mar 2017 17:43:07 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 2A0E0D806B1; Fri, 10 Mar 2017 18:43:17 +0100 (CET) Subject: Re: [PATCH] PR gdb/21226: Take DWARF stack value pieces from LSB end To: arnez@linux.vnet.ibm.com (Andreas Arnez) Date: Fri, 10 Mar 2017 17:43:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Andreas Arnez" at Mar 08, 2017 07:26:26 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17031017-0040-0000-0000-0000033F43DB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17031017-0041-0000-0000-000024785895 Message-Id: <20170310174317.2A0E0D806B1@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-10_11:,, 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-1702020001 definitions=main-1703100139 X-SW-Source: 2017-03/txt/msg00139.txt.bz2 Andreas Arnez wrote: > When taking a DW_OP_piece or DW_OP_bit_piece from a DW_OP_stack_value, the > existing logic always takes the piece from the lowest-addressed end, which > is wrong on big-endian targets. The DWARF standard states that the > "DW_OP_bit_piece operation describes a sequence of bits using the least > significant bits of that value", and this also matches the current logic > in GCC. For instance, the GCC guality test case pr54970.c fails on s390x > because of this. > > This fix adjusts the piece accordingly on big-endian targets. It is > assumed that: > > * DW_OP_piece shall take the piece from the LSB end as well; > > * pieces reaching outside the stack value bits are considered undefined, > and a zero value can be used instead. These assumptions look good to me. > The new logic also respects the DW_OP_bit_piece offset for > DW_OP_stack_values. Previously the offset was ignored. Note that it is > still ignored for all other types of DWARF pieces. I'm not really sure about that. If we're going to support the offset, shouldn't we then support it for all piece types? I'm not sure it is a good idea to support it for some but not others ... > case DWARF_VALUE_STACK: > { > - size_t n = this_size; > + ULONGEST obj_size = 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); c->addr_size is now unused. This is a left-over from the days when stack values were untyped, and were always assumed to be integers the size of a target address. Now that we have a proper typed stack, c->addr_size is not really relevant anymore. It should be completely removed from the piece_closure data structure (and all code that initializes it). > + /* Use zeroes if piece reaches beyond stack value. */ > + if (p->offset + p->size > obj_size) > + goto skip_copy; I'm not sure I like those gotos :-( > - if (p->location != DWARF_VALUE_OPTIMIZED_OUT > - && p->location != DWARF_VALUE_IMPLICIT_POINTER) > - copy_bitwise (contents, dest_offset_bits, > - intermediate_buffer, source_offset_bits % 8, > - this_size_bits, bits_big_endian); > + copy_bitwise (contents, dest_offset_bits, > + intermediate_buffer, source_offset_bits % 8, > + this_size_bits, bits_big_endian); > > + skip_copy: At this point, it seems better to just duplicate the copy_bitwise call to all those switch clauses that actually need it. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com