From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17142 invoked by alias); 13 Apr 2010 03:58:29 -0000 Received: (qmail 17131 invoked by uid 22791); 13 Apr 2010 03:58:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Apr 2010 03:58:24 +0000 Received: (qmail 7884 invoked from network); 13 Apr 2010 03:58:23 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Apr 2010 03:58:23 -0000 Message-ID: <4BC3EBD2.8090303@codesourcery.com> Date: Tue, 13 Apr 2010 03:58:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Mike Frysinger CC: gdb-patches@sourceware.org, Stan Shebs Subject: Re: [PATCH] Do partial xfers from trace file References: <4BBA5FE9.2060508@codesourcery.com> <201004122304.39043.vapier@gentoo.org> In-Reply-To: <201004122304.39043.vapier@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: 2010-04/txt/msg00394.txt.bz2 Mike Frysinger wrote: > On Monday 05 April 2010 18:10:49 Stan Shebs wrote: > >> Memory blocks in the trace buffer are limited to 65K (to save a couple >> bytes in the length field, since most blocks are small), and a tester >> trying to collect a quarter-megabyte(!) C++ object ran into trouble with >> that. The fix is really a target-side thing, but the trace file reader >> needs to cognizant of this detail also. Fortunately, we can exploit >> GDB's partial xfer mechanism, and just return what we find in one block, >> expecting that GDB will re-request the remainder. >> >> I also made the tfile target has_all_memory, and added an emulation of >> QTro behavior, which lets disassembly and the like work, but rejects >> attempts to print non-constant globals that were not collected. >> Committed to trunk. >> > > there's some problems with this commit ... > > it introduces a warning which breaks with -Werror: > tracepoint.c: In function ‘tfile_xfer_partial’: > tracepoint.c:3895: error: ignoring return value of ‘read’, declared with > attribute warn_unused_result > It's a little weird that some people get a complaint and others don't... In any case, it's just an oversight, all the other read results are being checked, and so I just committed the fix below. Stan 2010-04-12 Stan Shebs * tracepoint.c (tfile_xfer_partial): Check read result. Index: tracepoint.c =================================================================== RCS file: /cvs/src/src/gdb/tracepoint.c,v retrieving revision 1.177 diff -p -r1.177 tracepoint.c *** tracepoint.c 9 Apr 2010 20:46:40 -0000 1.177 --- tracepoint.c 13 Apr 2010 03:52:28 -0000 *************** tfile_xfer_partial (struct target_ops *o *** 3892,3898 **** if (amt > len) amt = len; ! read (trace_fd, readbuf, amt); return amt; } lseek (trace_fd, mlen, SEEK_CUR); --- 3892,3905 ---- if (amt > len) amt = len; ! gotten = read (trace_fd, readbuf, amt); ! if (gotten < 0) ! perror_with_name (trace_filename); ! /* While it's acceptable to return less than was ! originally asked for, it's not acceptable to return ! less than what this block claims to contain. */ ! else if (gotten < amt) ! error (_("Premature end of file while reading trace file")); return amt; } lseek (trace_fd, mlen, SEEK_CUR);