From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71049 invoked by alias); 11 Feb 2016 17:24:06 -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 71036 invoked by uid 89); 11 Feb 2016 17:24:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=bfd_endian_big, endaddr, *endaddr, BFD_ENDIAN_BIG 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Feb 2016 17:24:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3D86419CF24; Thu, 11 Feb 2016 17:24:03 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1BHO2Zs006653; Thu, 11 Feb 2016 12:24:02 -0500 Message-ID: <56BCC3B1.5090400@redhat.com> Date: Thu, 11 Feb 2016 17:24:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Clear *VAL in regcache_raw_read_unsigned References: <1455029644-6197-1-git-send-email-yao.qi@linaro.org> <86egckqztq.fsf@gmail.com> <56BB6ADB.6070909@redhat.com> <86a8n8qxyp.fsf@gmail.com> <56BB7512.2030507@redhat.com> <8660xvr1wr.fsf@gmail.com> <56BC829B.8060102@redhat.com> <864mdfp9b3.fsf@gmail.com> <56BCAE02.7030803@redhat.com> <56BCBE08.6040306@gmail.com> In-Reply-To: <56BCBE08.6040306@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00380.txt.bz2 On 02/11/2016 04:59 PM, Yao Qi wrote: > Hi Pedro, > > On 11/02/16 15:51, Pedro Alves wrote: >> I think it's only going to bite us back in the future. >> >> From the perspective of potentially making it easier to share more >> code between gdb and gdbserver, I'd prefer that. Would you object it? >> > > No, I am not against code sharing between GDB and GDBserver in general, > but sharing extract_unsigned_integer is not necessary for GDBserver. It's not like like we'd be bringing in some big complicated piece of code. The routines in question are quite small. It's about the same code as the other solution with the switch. Compare, gdb's: ULONGEST extract_unsigned_integer (const gdb_byte *addr, int len, enum bfd_endian byte_order) { ULONGEST retval; const unsigned char *p; const unsigned char *startaddr = addr; const unsigned char *endaddr = startaddr + len; if (len > (int) sizeof (ULONGEST)) error (_("\ That operation is not available on integers of more than %d bytes."), (int) sizeof (ULONGEST)); /* Start at the most significant end of the integer, and work towards the least significant. */ retval = 0; if (byte_order == BFD_ENDIAN_BIG) { for (p = startaddr; p < endaddr; ++p) retval = (retval << 8) | *p; } else { for (p = endaddr - 1; p >= startaddr; --p) retval = (retval << 8) | *p; } return retval; } vs gdbserver's, using a switch: ULONGEST extract_unsigned_integer (const gdb_byte *addr, int len) { uint8_t u8; uint16_t u16; uint32_t u32; uint64_t u64; if (len > (int) sizeof (ULONGEST)) error (_("That operation is not available on integers of more than" "%d bytes."), (int) sizeof (ULONGEST)); switch (len) { case 1: memcpy (&u8, addr, len); return u8; case 2: memcpy (&u16, addr, len); return u16; case 4: memcpy (&u32, addr, len); return u32; case 8: memcpy (&u64, addr, len); return u64; } } I just don't see what the worry is. OTOH, sharing the routines would pave to way to share more, and have one less diverging detail to worry about, avoiding proliferation of "bridging" interfaces like regcache_raw_read_unsigned or the need to hook in more entry points to get_next_pcs and whatever else we put in shared code areas. Thanks, Pedro Alves