From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24399 invoked by alias); 14 May 2010 20:02:08 -0000 Received: (qmail 24233 invoked by uid 22791); 14 May 2010 20:02:08 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Fri, 14 May 2010 20:02:03 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4EK22d8029395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 May 2010 16:02:02 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4EJNPfq022109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 15:23:27 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o4EJNPmJ027409; Fri, 14 May 2010 21:23:25 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o4EJNOpu027408; Fri, 14 May 2010 21:23:24 +0200 Date: Fri, 14 May 2010 20:14:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: fix bug in pieced value with offset Message-ID: <20100514192324.GA25176@host0.dyn.jankratochvil.net> References: <20100514110537.GA25586@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) 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: 2010-05/txt/msg00310.txt.bz2 On Fri, 14 May 2010 19:29:33 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > > Jan> Thinking now if the BFD_ENDIAN_BIG patch by Ulrich Weigand > Jan> [rfc] Handle DWARF-2 value pieces residing in *parts* of a register > Jan> http://sourceware.org/ml/gdb-patches/2009-12/msg00305.html > Jan> should not have been applied also for DWARF_VALUE_STACK; but this > Jan> is outside of the scope of this patch. > > I must be missing something... I don't see any change to > DWARF_VALUE_STACK there. I am sorry, s/should not have/should have/. Does it make sense now? > Jan> I believe it should be instead: > Jan> # + reg_offset = (register_size (arch, gdb_regnum) > Jan> # + - this_size); > > Jan> As we should ignore source_offset bytes from the start of register. > Jan> register_size = 8 > Jan> p-> size = 4 > Jan> bytes_to_skip = for example 1 > Jan> => > Jan> source_offset = 1 > Jan> this_size = 3 > > Jan> From the register occupying bytes <0..7> we thus want to read-in > Jan> bytes <5..7>. > > My thinking was to consider the resulting contents as a sequence of > bytes. In this case the register would be laid out from high byte to > low byte. yes. > The existing 'size' offsetting strips off high bytes (because > it is conceptually value-based); but then for 'source_offset' we want to > advance through the byte representation -- so, also skipping high bytes. Following my example of parameters written in my mail above. Let's have in big-ending 64bit register value 0xdeadf00dbaadbeef. It will be laid out inside get_frame_register_bytes as: offset: 0 1 2 3 4 5 6 7 value: 0xde, 0xad, 0xf0, 0x0d, 0xba, 0xad, 0xbe, 0xef This piece P is for `DW_OP_piece: 4'. value_offset is 1 (or larger if preceding pieces were involved). Therefore I believe we should read in 0xad, 0xbe, 0xef. Your patch reads in 0xba, 0xad, 0xbe. > I can't tell if this makes sense or not. I am not sure if your sentence was agreeing with my suggested change or not. > >> case DWARF_VALUE_STACK: > >> { > >> struct gdbarch *gdbarch = get_type_arch (value_type (v)); > >> - size_t n = p->size; > >> + size_t n = this_size; > >> if (n > c->addr_size) > >> n = c->addr_size; > > Jan> Generally I would prefer more sanity checks there instead of quiet data > Jan> cutting. > > In this particular case, I think this is just what DWARF specifies. I find this case (n > c->addr_size) as not described => undefined by DWARF. > I think it makes sense to compute a value on the stack and then just > select some bits from it. I agree with your sentence. I do not agree your sentence describes your code. The comparison present in code is exactly the opposite one. Your sentence describes "n < c->addr_size". DWARF DW_OP_piece must be arch aware. arch (specifically cu_header.addr_size) specifies c->addr_size. DW_OP_piece parameter N must be aware of c->addr_size. DWARF4 2.5.1 says: Each element of the stack is the size of an address on the target machine. Therefore I find DW_OP_piece trying to use more bytes from DWARF_VALUE_STACK (DW_OP_piece must be aware it is referencing a DWARF_VALUE_STACK value) than what is size of the DWARF_VALUE_STACK object as an error in input DWARF. > Maybe for DWARF_VALUE_LITERAL it would make sense to issue a complaint > if the piece is smaller than the literal. That would be strange > compiler output. I did not think about this case. I agree. Thanks, Jan