From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18370 invoked by alias); 10 Nov 2009 19:37:36 -0000 Received: (qmail 18351 invoked by uid 22791); 10 Nov 2009 19:37:34 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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, 10 Nov 2009 19:37:30 +0000 Received: (qmail 29629 invoked from network); 10 Nov 2009 19:37:28 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Nov 2009 19:37:28 -0000 From: Pedro Alves To: Stan Shebs Subject: Re: Remove m68k-elf special cases from gdb.trace Date: Tue, 10 Nov 2009 19:37:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, Michael Snyder References: <20091102012332.GA31878@caradoc.them.org> <200911101249.03859.pedro@codesourcery.com> <4AF9ADBE.4060409@codesourcery.com> In-Reply-To: <4AF9ADBE.4060409@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911101937.27789.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2009-11/txt/msg00225.txt.bz2 On Tuesday 10 November 2009 18:15:26, Stan Shebs wrote: > Pedro Alves wrote: > > gdb/agentexpr.texi has section "Tracing on Symmetrix" that I > > think should be dropped as well. > > > Agreed. It's an interesting historical tidbit, but historians can go dig > up an old rev if they really want to research it. Should be obvious, but... Okay? -- Pedro Alves 2009-11-10 Pedro Alves gdb/doc/ * agentexpr.texi (Tracing On Symmetrix): Delete section. (Using Agent Expressions): Delete cross reference. --- gdb/doc/agentexpr.texi | 142 ------------------------------------------------- 1 file changed, 1 insertion(+), 141 deletions(-) Index: src/gdb/doc/agentexpr.texi =================================================================== --- src.orig/gdb/doc/agentexpr.texi 2009-11-10 19:21:11.000000000 +0000 +++ src/gdb/doc/agentexpr.texi 2009-11-10 19:26:00.000000000 +0000 @@ -58,8 +58,6 @@ debugging agent in real-time application * Bytecode Descriptions:: What each one does. * Using Agent Expressions:: How agent expressions fit into the big picture. * Varying Target Capabilities:: How to discover what the target can do. -* Tracing on Symmetrix:: Special info for implementation on EMC's - boxes. * Rationale:: Why we did it this way. @end menu @@ -503,9 +501,7 @@ GDB transmits the tracepoints and their GDB agent, running on the debugging target. @item -The agent arranges to be notified when a trace point is hit. Note that, -on some systems, the target operating system is completely responsible -for collecting the data; see @ref{Tracing on Symmetrix}. +The agent arranges to be notified when a trace point is hit. @item When execution on the target reaches a trace point, the agent evaluates @@ -559,142 +555,6 @@ whether the target supports disabled tra @end itemize - - -@node Tracing on Symmetrix -@section Tracing on Symmetrix - -This section documents the API used by the GDB agent to collect data on -Symmetrix systems. - -Cygnus originally implemented these tracing features to help EMC -Corporation debug their Symmetrix high-availability disk drives. The -Symmetrix application code already includes substantial tracing -facilities; the GDB agent for the Symmetrix system uses those facilities -for its own data collection, via the API described here. - -@deftypefn Function DTC_RESPONSE adbg_find_memory_in_frame (FRAME_DEF *@var{frame}, char *@var{address}, char **@var{buffer}, unsigned int *@var{size}) -Search the trace frame @var{frame} for memory saved from @var{address}. -If the memory is available, provide the address of the buffer holding -it; otherwise, provide the address of the next saved area. - -@itemize @bullet - -@item -If the memory at @var{address} was saved in @var{frame}, set -@code{*@var{buffer}} to point to the buffer in which that memory was -saved, set @code{*@var{size}} to the number of bytes from @var{address} -that are saved at @code{*@var{buffer}}, and return -@code{OK_TARGET_RESPONSE}. (Clearly, in this case, the function will -always set @code{*@var{size}} to a value greater than zero.) - -@item -If @var{frame} does not record any memory at @var{address}, set -@code{*@var{size}} to the distance from @var{address} to the start of -the saved region with the lowest address higher than @var{address}. If -there is no memory saved from any higher address, set @code{*@var{size}} -to zero. Return @code{NOT_FOUND_TARGET_RESPONSE}. -@end itemize - -These two possibilities allow the caller to either retrieve the data, or -walk the address space to the next saved area. -@end deftypefn - -This function allows the GDB agent to map the regions of memory saved in -a particular frame, and retrieve their contents efficiently. - -This function also provides a clean interface between the GDB agent and -the Symmetrix tracing structures, making it easier to adapt the GDB -agent to future versions of the Symmetrix system, and vice versa. This -function searches all data saved in @var{frame}, whether the data is -there at the request of a bytecode expression, or because it falls in -one of the format's memory ranges, or because it was saved from the top -of the stack. EMC can arbitrarily change and enhance the tracing -mechanism, but as long as this function works properly, all collected -memory is visible to GDB. - -The function itself is straightforward to implement. A single pass over -the trace frame's stack area, memory ranges, and expression blocks can -yield the address of the buffer (if the requested address was saved), -and also note the address of the next higher range of memory, to be -returned when the search fails. - -As an example, suppose the trace frame @code{f} has saved sixteen bytes -from address @code{0x8000} in a buffer at @code{0x1000}, and thirty-two -bytes from address @code{0xc000} in a buffer at @code{0x1010}. Here are -some sample calls, and the effect each would have: - -@table @code - -@item adbg_find_memory_in_frame (f, (char*) 0x8000, &buffer, &size) -This would set @code{buffer} to @code{0x1000}, set @code{size} to -sixteen, and return @code{OK_TARGET_RESPONSE}, since @code{f} saves -sixteen bytes from @code{0x8000} at @code{0x1000}. - -@item adbg_find_memory_in_frame (f, (char *) 0x8004, &buffer, &size) -This would set @code{buffer} to @code{0x1004}, set @code{size} to -twelve, and return @code{OK_TARGET_RESPONSE}, since @file{f} saves the -twelve bytes from @code{0x8004} starting four bytes into the buffer at -@code{0x1000}. This shows that request addresses may fall in the middle -of saved areas; the function should return the address and size of the -remainder of the buffer. - -@item adbg_find_memory_in_frame (f, (char *) 0x8100, &buffer, &size) -This would set @code{size} to @code{0x3f00} and return -@code{NOT_FOUND_TARGET_RESPONSE}, since there is no memory saved in -@code{f} from the address @code{0x8100}, and the next memory available -is at @code{0x8100 + 0x3f00}, or @code{0xc000}. This shows that request -addresses may fall outside of all saved memory ranges; the function -should indicate the next saved area, if any. - -@item adbg_find_memory_in_frame (f, (char *) 0x7000, &buffer, &size) -This would set @code{size} to @code{0x1000} and return -@code{NOT_FOUND_TARGET_RESPONSE}, since the next saved memory is at -@code{0x7000 + 0x1000}, or @code{0x8000}. - -@item adbg_find_memory_in_frame (f, (char *) 0xf000, &buffer, &size) -This would set @code{size} to zero, and return -@code{NOT_FOUND_TARGET_RESPONSE}. This shows how the function tells the -caller that no further memory ranges have been saved. - -@end table - -As another example, here is a function which will print out the -addresses of all memory saved in the trace frame @code{frame} on the -Symmetrix INLINES console: -@example -void -print_frame_addresses (FRAME_DEF *frame) -@{ - char *addr; - char *buffer; - unsigned long size; - - addr = 0; - for (;;) - @{ - /* Either find out how much memory we have here, or discover - where the next saved region is. */ - if (adbg_find_memory_in_frame (frame, addr, &buffer, &size) - == OK_TARGET_RESPONSE) - printp ("saved %x to %x\n", addr, addr + size); - if (size == 0) - break; - addr += size; - @} -@} -@end example - -Note that there is not necessarily any connection between the order in -which the data is saved in the trace frame, and the order in which -@code{adbg_find_memory_in_frame} will return those memory ranges. The -code above will always print the saved memory regions in order of -increasing address, while the underlying frame structure might store the -data in a random order. - -[[This section should cover the rest of the Symmetrix functions the stub -relies upon, too.]] - @node Rationale @section Rationale