From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 986 invoked by alias); 23 Jan 2013 14:22:40 -0000 Received: (qmail 976 invoked by uid 22791); 23 Jan 2013 14:22:37 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from db3ehsobe001.messaging.microsoft.com (HELO db3outboundpool.messaging.microsoft.com) (213.199.154.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jan 2013 14:22:32 +0000 Received: from mail53-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 14:22:30 +0000 Received: from mail53-db3 (localhost [127.0.0.1]) by mail53-db3-R.bigfish.com (Postfix) with ESMTP id C288F180405; Wed, 23 Jan 2013 14:22:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:59.163.77.45;KIP:(null);UIP:(null);IPV:NLI;H:KCHJEXHC01.kpit.com;RD:59.163.77.45.static.vsnl.net.in;EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz1432I4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail53-db3 (localhost.localdomain [127.0.0.1]) by mail53-db3 (MessageSwitch) id 1358950949721747_28038; Wed, 23 Jan 2013 14:22:29 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.249]) by mail53-db3.bigfish.com (Postfix) with ESMTP id ACC0B34006E; Wed, 23 Jan 2013 14:22:29 +0000 (UTC) Received: from KCHJEXHC01.kpit.com (59.163.77.45) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 14:22:24 +0000 Received: from KCHJEXMB02.kpit.com ([169.254.2.51]) by KCHJEXHC01.kpit.com ([172.10.15.73]) with mapi id 14.02.0247.003; Wed, 23 Jan 2013 19:52:21 +0530 From: Kaushik Phatak To: Pedro Alves CC: Joel Brobecker , "gdb-patches@sourceware.org" , Yao Qi , Tom Tromey Subject: RE: [RFA 3/5] New port: CR16: gdb port Date: Wed, 23 Jan 2013 14:22:00 -0000 Message-ID: References: <20121022224107.GB3713@adacore.com> <20121023135502.GA3555@adacore.com> <20121115174313.GC3790@adacore.com> <20121122175010.GG9964@adacore.com> <20130117085919.GA3564@adacore.com> <20130118141649.GK3564@adacore.com> <50FEABC8.2040805@redhat.com> In-Reply-To: <50FEABC8.2040805@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kpitcummins.com 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: 2013-01/txt/msg00550.txt.bz2 > I think we should hold the gdb bits until the gdbserver parts are settled, > as we're discussing core register numbering issues. > What did you think of my suggestions/comments to the gdb patch? Yes, I do want to address those as well :) > How about exporting a function that hides these opcodes details?=20=20 > I don't even pretend to understand what the code is trying to do,=20 > and it'd be an opportunity to comment it in the function description. > /* Take BUF, do something with it, and write length > to LENGTH. Blah, blah. */ > cr16_do_something (buf, *length, ...); I think this can be done and it will make this code look cleaner. An exported function in bfd would make my code look like this, ... target_read_memory (pc, buf, 6); cr16_get_insn_length (buf, *length, ...); next_pc =3D pc + length; ... > > + "r0r1_orig", > This too looks like a ptrace detail escaping all the > way to the user, similar to the gdbserver issues. > Any reason not to split those up? I think it'd be nicer.=09 This is a kernel scratch register and it part of PT_REGS. Would be OK to leave it as is as it may help in debugging? Thanks, Kaushik