From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31970 invoked by alias); 18 Apr 2017 16:32:03 -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 31957 invoked by uid 89); 18 Apr 2017 16:32:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=thoughts, Let's, 201601 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; Tue, 18 Apr 2017 16:32:01 +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 v3IGNkjv107451 for ; Tue, 18 Apr 2017 12:32:02 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 29wmqrna9k-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Apr 2017 12:32:01 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Apr 2017 17:32:00 +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; Tue, 18 Apr 2017 17:31:57 +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 v3IGVusu4063742; Tue, 18 Apr 2017 16:31:56 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6B9BDAE053; Tue, 18 Apr 2017 17:30:43 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 38675AE055; Tue, 18 Apr 2017 17:30:43 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.162]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 18 Apr 2017 17:30:43 +0100 (BST) From: Andreas Arnez To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/9] PR gdb/21226: Take DWARF stack value pieces from LSB end References: <1491586736-21296-1-git-send-email-arnez@linux.vnet.ibm.com> <1491586736-21296-4-git-send-email-arnez@linux.vnet.ibm.com> <0144cae486cd82860db324db6f2e1e1e@polymtl.ca> Date: Tue, 18 Apr 2017 16:32:00 -0000 In-Reply-To: <0144cae486cd82860db324db6f2e1e1e@polymtl.ca> (Simon Marchi's message of "Thu, 13 Apr 2017 23:36:15 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17041816-0040-0000-0000-0000036C6E7B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041816-0041-0000-0000-000025009ACC Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-18_13:,, 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-1704180129 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00512.txt.bz2 On Thu, Apr 13 2017, Simon Marchi wrote: > On 2017-04-07 13:38, 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. > > I'd like if you could clarify this (just here not necessarily in the > patch). DWARF locations are computed inside GDB, on the host. So does it > really depend on the target endianness, or it's that of the host, or both? > > Let's consider these cases of remote debugging: > > host -> target > x86 -> x86 > x86 -> s390 > s390 -> x86 > s390 -> s390 > > In which cases is the value found at the high memory address vs low memory > address? DWARF stack values are represented in the target architecture's endianness, independent from the host. For instance, if the target is x86, then the DWARF stack uses little-endian byte order, even on s390 hosts. See also dwarf_expr_context::execute_stack_op(). [...] >> >> 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 obj_size = 8 * TYPE_LENGTH (value_type (p->v.value)); > > It would be really nice for the readers if you could put some comment like > this, even though it may seem obvious to you: > > /* The size of a DWARF stack value. */ > ULONGEST obj_size = 8 * TYPE_LENGTH (value_type (p->v.value)); > > I found I had to add them to the code to be able to follow. OK, but it seems that the variable name 'obj_size' causes the confusion; so I'd rather skip the comment, change the variable name to stack_value_size_bits instead and let it speak for itself. > >> >> - 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 > obj_size) >> + break; > > Does this happen, for example, if a DWARF stack value is 32 bits long, but > the piece is 64 bits? I suppose that's not something we'd want a compiler > to emit, and would be considered a bug in the compiler? Yes, right now I would consider it a compiler bug. And I haven't seen a compiler emit such DWARF code yet. This is just to avoid crashing GDB, and to behave predictably instead if it occurs anyway. (If you're interested, I've written more thoughts about this topic in section 5, "padding", of this article: https://sourceware.org/ml/gdb/2016-01/msg00013.html) > > How does breaking out of the loop will use zeroes? Is the value buffer > cleared beforehand? Yes, value_contents_raw returns a zeroed buffer. > >> >> - intermediate_buffer = val_bytes + source_offset; >> - } >> + /* Piece is anchored at least significant bit end. */ >> + if (gdbarch_byte_order (objfile_gdbarch) == BFD_ENDIAN_BIG) >> + source_offset_bits += obj_size - p->size; > > Just a nit, but I find it more readable when there's an empty line between > the if and the following lines not included in the if (so here, right > where I cut the quote). It reads like two separate sentences: > > - If the byte order is big endian, adjust offset in the source. > - Copy bitwise from the source buffer to the destination buffer. OK. > >> + copy_bitwise (contents, dest_offset_bits, >> + value_contents_all (p->v.value), >> + source_offset_bits, >> + this_size_bits, bits_big_endian); > > Thanks, > > Simon Thanks, Andreas