From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14191 invoked by alias); 4 Jun 2007 22:59:27 -0000 Received: (qmail 14183 invoked by uid 22791); 4 Jun 2007 22:59:26 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Jun 2007 22:59:23 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l54MxKKo118874 for ; Mon, 4 Jun 2007 22:59:20 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l54MxKAp3985436 for ; Tue, 5 Jun 2007 00:59:20 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l54MxK2l025173 for ; Tue, 5 Jun 2007 00:59:20 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l54MxK0A025170; Tue, 5 Jun 2007 00:59:20 +0200 Message-Id: <200706042259.l54MxK0A025170@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 5 Jun 2007 00:59:20 +0200 Subject: Re: [rfc/rfa] [4/4] SPU enhancements: GDB/MI extensions To: drow@false.org (Daniel Jacobowitz) Date: Mon, 04 Jun 2007 22:59:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, eliz@gnu.org In-Reply-To: <20070604202224.GA26302@caradoc.them.org> from "Daniel Jacobowitz" at Jun 04, 2007 04:22:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2007-06/txt/msg00046.txt.bz2 Daniel Jacobowitz wrote: > Right, but I didn't mean something quite that ambitious. What does > the IDE end up doing with the output of these commands, and does it > want to parse them or just display them as text? It certainly parses the information for display; for example, the -spu-info-dma command results in output like (added whitespace for better readability): (gdb) -spu-info-dma ^done,SPUInfoDMA= { dma_info_type="0x0", dma_info_mask="0x20", dma_info_status="0x0", dma_info_stall_and_notify="0x0", dma_info_atomic_command_status="0x0", dma_cmd= { nr_rows="16", nr_cols="10", hdr=[{width="7",alignment="-1",col_name="opcode",colhdr="Opcode"}, {width="3",alignment="-1",col_name="tag",colhdr="Tag"}, {width="3",alignment="-1",col_name="tid",colhdr="TId"}, {width="3",alignment="-1",col_name="rid",colhdr="RId"}, {width="18",alignment="-1",col_name="ea",colhdr="EA"}, {width="7",alignment="-1",col_name="lsa",colhdr="LSA"}, {width="7",alignment="-1",col_name="size",colhdr="Size"}, {width="7",alignment="-1",col_name="lstaddr",colhdr="LstAddr"}, {width="7",alignment="-1",col_name="lstsize",colhdr="LstSize"}, {width="1",alignment="-1",col_name="error_p",colhdr="E"}], body=[cmd={opcode="getl",tag="0",tid="0",rid="0", ea="0xd00000000029f000",lsa="0x00000",size="0x00000", lstaddr="0x00e70",lstsize="0x00008",error_p=""}, cmd={opcode="putllc",tag="0",tid="0",rid="0", ea="0xd000000000250080",lsa="0x00080",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="get",tag="5",tid="0",rid="0", ea="0x00000000f7f90000",lsa="0x01a00",size="0x00080", lstaddr="",lstsize="",error_p=""}, cmd={opcode="mfcsync",tag="0",tid="0",rid="0",ea="", lsa="0x00300",size="0x00880", lstaddr="",lstsize="",error_p=""}, cmd={opcode="get",tag="0",tid="0",rid="0", ea="0xd000000000250900",lsa="0x00e00",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}, cmd={opcode="0",tag="0",tid="0",rid="0", ea="",lsa="0x00000",size="0x00000", lstaddr="",lstsize="",error_p=""}] } } This corresponds to the information shown by "info spu dma" in the CLI: (gdb) info spu dma Tag-Group Status 0x00000000 Tag-Group Mask 0x00000020 (no query pending) Stall-and-Notify 0x00000000 Atomic Cmd Status 0x00000000 Opcode Tag TId RId EA LSA Size LstAddr LstSize E getl 0 0 0 0xd00000000029f000 0x00000 0x00000 0x00e70 0x00008 putllc 0 0 0 0xd000000000250080 0x00080 0x00000 get 5 0 0 0x00000000f7f90000 0x01a00 0x00080 mfcsync 0 0 0 0x00300 0x00880 get 0 0 0 0xd000000000250900 0x00e00 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 0 0 0 0 0x00000 0x00000 The IDE parses the above MI output to display a screen that shows this information, formatted appropriately. > I have a half-finished sketch of a register groups interface that lets > GDB present arbitrary control structures from the target as > "registers" to the front end. There will be a generic MI command to > get groups of these things and the individual members will show up > through -var-list-children as varobjs. But that may not be suitable. > > Another option would be something like this, if the output of the MI > commands is general enough. Excuse my MI syntax if it's completely > wrong, please. > > -> -arch-info-list > <- ^done,infos=["spu dma", "spu signals"] > -> -arch-info "spu dma" > <- ^done,[whatever] It would appear that this makes sense only if the IDE is capable of generically displaying any such -arch-info output. This is a bit different from our current -spu-info implementation where the IDE has its own understanding of each of the various commands, and how to best display the result of each of them. I'll get in touch with our IDE group and find out if they feel a "generic" info display facility would be feasible / useful ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com