From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89271 invoked by alias); 21 Dec 2016 21:39:34 -0000 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 Received: (qmail 89260 invoked by uid 89); 21 Dec 2016 21:39:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=world, world!, structured, notion X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Dec 2016 21:39:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E64A83F38; Wed, 21 Dec 2016 21:39:31 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-204-24.brq.redhat.com [10.40.204.24]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBLLdRsd014042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Dec 2016 16:39:30 -0500 Date: Wed, 21 Dec 2016 21:39:00 -0000 From: Jan Kratochvil To: Andreas Arnez Cc: GDB Development , Tom Tromey Subject: Re: Should a DW_OP_implicit_value be taken from the left end? Message-ID: <20161221213927.GA2306@host1.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00031.txt.bz2 On Wed, 21 Dec 2016 20:42:25 +0100, Andreas Arnez wrote: > Since DW_OP_implicit_value can express arbitrary amounts of structured > or unstructured data, the notion of a "least significant byte" is > meaningless. That depends on what the compiler-debugger negotiate together, as specified by the DWARF standard which is ambiguous in this case IIUC. > The patch above makes it impossible for a > DW_OP_implicit_pointer operation to refer to any sub-value within a > DW_OP_implicit_value on big-endian targets. When looking at the patch I think the patch may be wrong, I think the endianity should affect at least also the lines: case DWARF_VALUE_LITERAL: ... ldata = ctx.data + byte_offset; n -= byte_offset; > E.g., consider this code snippet: > > const char foo[] = "Hello, world!"; > char *a = &foo[0]; > char *b = &foo[7]; > > IMHO the compiler should be able to describe `foo' with a single > DW_OP_implicit_value operation and `a' and `b' as DW_OP_implicit_pointer > operations pointing into that value. I would need a compilable + compiled code + DWARF output + GDB output to say more. > Any objections? I really do not mind reverting the patch if you think so, that is up to the maintainers. But when you ask me I miss here stating what the current GCC version does produce. Is GDB behavior fixed with current GCC by your proposed patch revert? If it breaks do you plan to change/fix also GCC? Does the GDB testsuite (particulerly the entryval testcases) have no regressions on s390*? >From my mail you reference I understand it as that my patch did fix some entryval testcases with GCC that time. Unfortunately the entryval testcases are provided as .S files prebuilt by GCC that time and they are difficult to reproduce with newer GCC as -O2 -g code changes too much with different GCC version, breaking various compiled code assumptions of the .exp file. My feeling is that my patch did fix some entryval testcases on bigendian but I also guess my patch was wrong - it only accidentally fixed them, the right fix for big endian should look differently. Jan