From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15081 invoked by alias); 26 Jun 2013 10:32:30 -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 15048 invoked by uid 89); 26 Jun 2013 10:32:27 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 10:32:26 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5QAWNvU014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 06:32:23 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5QAWKLn027582; Wed, 26 Jun 2013 06:32:21 -0400 Message-ID: <51CAC334.7040700@redhat.com> Date: Wed, 26 Jun 2013 10:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kaushik Phatak CC: "gdb-patches@sourceware.org" , Joel Brobecker Subject: Re: [RFA 3/5] New port: CR16: gdb port 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: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00762.txt.bz2 On 06/26/2013 08:02 AM, Kaushik Phatak wrote: > 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 > this register to prevent a SIGSEGV or SIGILL similar to amd64_linux_write_pc. > The signal handler checks for "regs->orig_r0and1 >= 0" before performing a -ERESTARTSYS > I will add this register to linux-tdep in gdb as well as the gdbserver port, ok? Sounds good. You should put that register in a separate target description feature. See: $ find features/ -name "*.xml" | xargs grep orig_ features/s390x-linux64v2.xml: features/rs6000/power-linux.xml: features/rs6000/power64-linux.xml: features/s390-linux64v2.xml: features/s390-linux64.xml: features/s390-linux64v1.xml: features/s390-linux32v2.xml: features/s390x-linux64v1.xml: features/i386/32bit-linux.xml: features/i386/64bit-linux.xml: features/s390-linux32.xml: features/s390-linux32v1.xml: features/s390x-linux64.xml: And: $ grep tdesc_find_feature * | grep linux amd64-linux-tdep.c: feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux"); amd64-linux-tdep.c: feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux"); i386-linux-tdep.c: feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux"); i386-linux-tdep.c: if (tdesc_find_feature (tdesc, "org.gnu.gdb.i386.avx")) i386-linux-tdep.c: else if (tdesc_find_feature (tdesc, "org.gnu.gdb.i386.sse")) mips-linux-tdep.c: feature = tdesc_find_feature (info.target_desc, ppc-linux-tdep.c: if (tdesc_find_feature (info.target_desc, ppc-linux-tdep.c: else if (tdesc_find_feature (info.target_desc, ppc-linux-tdep.c: if (tdesc_find_feature (info.target_desc, ppc-linux-tdep.c: else if (tdesc_find_feature (info.target_desc, ppc-linux-tdep.c: feature = tdesc_find_feature (info.target_desc, s390-tdep.c: feature = tdesc_find_feature (tdesc, "org.gnu.gdb.s390.linux"); > >>> Are these always present in all versions of CR16 silicon? IOW, are >>> we safe with adding them to the core register set (*)? >>> (*) 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 registers, > "dbs","dcrl","dsr","car0","car1" > These registers are not part of every silicon and can be an optional feature. > However, the current simulator port seems to support these by default. Sure, but remote debugging such part with e.g., jtag should still be supported. > >>> you should really split them to a separate target description feature. > Is there any other port i can refer for this? Look for tdesc_find_feature. Maybe tic6x_gdbarch_init would be a simple enough reference. > I will run through my code again and work on the other formatting related comments > provided. Thanks. -- Pedro Alves