From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24470 invoked by alias); 26 Jun 2013 07:03:29 -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 24438 invoked by uid 89); 26 Jun 2013 07:03:24 -0000 X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from mail-db9lp0249.outbound.messaging.microsoft.com (HELO db9outboundpool.messaging.microsoft.com) (213.199.154.249) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 07:03:23 +0000 Received: from mail170-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 07:03:19 +0000 Received: from mail170-db9 (localhost [127.0.0.1]) by mail170-db9-R.bigfish.com (Postfix) with ESMTP id BD2FD420070; Wed, 26 Jun 2013 07:03:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:59.163.77.177;KIP:(null);UIP:(null);IPV:NLI;H:KCHJEXHC02.kpit.com;RD:59.163.77.177.static.vsnl.net.in;EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zz4015I179dNzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail170-db9 (localhost.localdomain [127.0.0.1]) by mail170-db9 (MessageSwitch) id 1372230198877189_28856; Wed, 26 Jun 2013 07:03:18 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.246]) by mail170-db9.bigfish.com (Postfix) with ESMTP id CE51C160055; Wed, 26 Jun 2013 07:03:18 +0000 (UTC) Received: from KCHJEXHC02.kpit.com (59.163.77.177) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Jun 2013 07:03:08 +0000 Received: from KCHJEXMB02.kpit.com ([169.254.2.54]) by KCHJEXHC02.kpit.com ([172.10.15.74]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 12:32:06 +0530 From: Kaushik Phatak To: Pedro Alves CC: "gdb-patches@sourceware.org" , Joel Brobecker Subject: RE: [RFA 3/5] New port: CR16: gdb port Date: Wed, 26 Jun 2013 07:08: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> <510002E0.7070806@redhat.com> <51C9E479.8090709@redhat.com> In-Reply-To: <51C9E479.8090709@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kpitcummins.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-SW-Source: 2013-06/txt/msg00757.txt.bz2 Hi Pedro, Thanks for another round of detailed review. >> Hmm. Just to be clear, isn't exposing r0_orig to gDB necessary for >> syscall restarting, like orig_eax/orig_rax on x86/x86_64, orig_r3 on ppc, >> orig_r2 on s390, etc.? See e.g., i386_linux_write_pc, amd64_linux_write= _pc, >> ppc_linux_write_pc, s390_write_pc. The original PTRACE implementation disallowed write to orig_r0and1, however= read was permitted. We can implement this as suggested above, so user may write = a -1 to=20 this register to prevent a SIGSEGV or SIGILL similar to amd64_linux_write_p= c. The signal handler checks for "regs->orig_r0and1 >=3D 0" before performing = a -ERESTARTSYS I will add this register to linux-tdep in gdb as well as the gdbserver port= , ok? >> Are these always present in all versions of CR16 silicon? IOW, are >> we safe with adding them to the core register set (*)?=20=20 >> (*) which registers are those btw? I'm not that familiar with CR16. :-) The following 5 registers have been added to this patch, which are debug re= gisters, "dbs","dcrl","dsr","car0","car1" These registers are not part of every silicon and can be an optional featur= e. However, the current simulator port seems to support these by default. >> you should really split them to a separate target description feature. Is there any other port i can refer for this?=20=20 I will run through my code again and work on the other formatting related c= omments provided. Thanks, Kaushik