From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74979 invoked by alias); 17 Mar 2015 13:48:55 -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 74811 invoked by uid 89); 17 Mar 2015 13:48:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e36.co.us.ibm.com Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 17 Mar 2015 13:48:50 +0000 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Mar 2015 07:48:49 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Mar 2015 07:48:47 -0600 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id D18D81FF0021 for ; Tue, 17 Mar 2015 07:39:57 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2HDkwSC32702592 for ; Tue, 17 Mar 2015 06:47:06 -0700 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2HDmDSn032331 for ; Tue, 17 Mar 2015 07:48:14 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id t2HDmBfN030766; Tue, 17 Mar 2015 07:48:12 -0600 Message-Id: <201503171348.t2HDmBfN030766@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 17 Mar 2015 14:47:47 +0100 Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le To: cole945@gmail.com (Wei-cheng Wang) Date: Tue, 17 Mar 2015 13:48:00 -0000 From: "Ulrich Weigand" Cc: palves@redhat.com, gdb-patches@sourceware.org In-Reply-To: <54F34F6B.2090105@gmail.com> from "Wei-cheng Wang" at Mar 02, 2015 01:42:03 AM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15031713-0021-0000-0000-000009450468 X-SW-Source: 2015-03/txt/msg00487.txt.bz2 Wei-cheng Wang wrote: > On 2015/2/28 上午 03:52, Ulrich Weigand wrote: > > The tspeed.exp file already has: > > # Typically we need a little extra time for this test. > > set timeout 180 > > Is that still not enough? > > It should include the time spent in trying different loop counts, > so it would be 11 + 22 + 45 + 90 + 180 = at least 348 seconds in my environment. > (for 10000, 20000, 40000, 80000, 160000 iterations respectively) > If I set timeout to 360, the case will pass. I guess that's OK with me. Or else we could reduce the number of passes ... > >> * tfind.exp: One of the tracepoint is inserted at > >> `*gdb_recursion_test'. It's not hit because local-entry is called > >> instead. The 18 FAILs are off-by-one error. > > This test case seem a bit more complicated, we may need to split it > > in two parts; one that uses a normal "trace gdb_recursion_test" > > without the "*", and possibly a second one that specifically tests > > that "trace *func" works, using a source file that makes sure to > > call func via a function pointers (as in step-bt.c). > > How about simply change the code to this? It wouldn't hurt other cases. > And all the failed cases in tfind.exp now pass. That should be OK. > > This is odd, I don't see the point of this either. Of course, as the > > comment says, much of this stuff will break anyway if gdbserver is > > compiled differently than the inferior (e.g. a 64-bit gdbserver > > debugging a 32-bit inferior), because it assumes the structure layout > > is identical. However, if we do have a 32-bit gdbserver, then I don't > > see why it shouldn't be possible to debug a 32-bit inferior, just > > because CORE_ADDR is a 64-bit type ... > > For example, CORE_ADDR ptr = 0x11223344, a 32-bit address, > and sizeof (void *) = 4-byte > > |------------ 64-bit CORE_ADDR ---------| > MSB LSB > | 00 | 00 | 00 | 00 | 11 | 22 | 33 | 44 | > Low High Address > |-- 32-bit(void*) --| > &ptr,4 means these zeros are written to inferior. > > static int > write_inferior_data_ptr (CORE_ADDR where, CORE_ADDR ptr) > { > return write_inferior_memory (where, > (unsigned char *) &ptr, sizeof (void *)); > ^^^^ ^^^^^^^^^^^^^^^ > } > > CORE_ADDR is declared as "unsigned long long" for gdbserver > (in common/gdb/common-types.h) I understood why this is failing with the code as is, I just didn't understand why the code is that way today :-) Given Pedro's comment, I think we should simply remove that function. > > Ugh. That's a strange construct, and extremely dependent on alignment > > rules (as you noticed). I'm not really sure what the best way to fix > > this would be. My preference right now would be get rid of "ops" on > > the gdbserver side too, and just switch on "type" in the two places > > where the ops->send and ops->download routines are called right now. > > > > This makes the data structures the same on gdbserver and IPA, which > > simplifies downloading quite a bit. (Also, it keeps the data structure > > identical in IPA, which should avoid compatibility issues between > > versions.) > That sounds great to me! OK, let's do it that way. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com