From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16601 invoked by alias); 12 Oct 2016 08:25:35 -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 16575 invoked by uid 89); 12 Oct 2016 08:25:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=top-level, bonus X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 08:25:33 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9C8NsYf069691 for ; Wed, 12 Oct 2016 04:25:31 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 261e6p245v-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2016 04:25:31 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 12 Oct 2016 09:25:29 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 12 Oct 2016 09:25:27 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 97D1017D8063; Wed, 12 Oct 2016 09:27:35 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u9C8PRcd22282310; Wed, 12 Oct 2016 08:25:27 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u9C8PQpk032219; Wed, 12 Oct 2016 04:25:27 -0400 Received: from oc8523832656.ibm.com (icon-9-164-182-54.megacenter.de.ibm.com [9.164.182.54]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u9C8PQka032213; Wed, 12 Oct 2016 04:25:26 -0400 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id 3250910FDC3; Wed, 12 Oct 2016 10:25:25 +0200 (CEST) Subject: Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER. To: bergner@vnet.ibm.com (Peter Bergner) Date: Wed, 12 Oct 2016 08:25:00 -0000 From: "Ulrich Weigand" Cc: palves@redhat.com (Pedro Alves), amodra@gmail.com (Alan Modra), gdb-patches@sourceware.org, binutils@sourceware.org (binutils) In-Reply-To: <8bfd2bd6-c2b3-cf5e-c689-897b877970f1@vnet.ibm.com> from "Peter Bergner" at Oct 11, 2016 01:48:55 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16101208-0016-0000-0000-00000249E899 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16101208-0017-0000-0000-0000235F2798 Message-Id: <20161012082525.3250910FDC3@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-12_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120138 X-SW-Source: 2016-10/txt/msg00290.txt.bz2 Peter Bergner wrote: > On 10/10/16 7:08 PM, Pedro Alves wrote: > > A command that works for all architectures, like your original > > "set disassembler-cpu" seemingly would be (ignoring implementation > > details). Maybe "set disassembler-cpu" could be an alias for > > "set $current_arch disassembler-cpu". GDB would then only need to store > > a disassemble option string for each possible arch, and the alias would just > > need to map the current arch's cpu to the right option string variable. > > It doesn't look like set_disassembler_cpu() is passed the gdbarch, so > is there some global variable that it could use to determine what the > current arch is? That said, even if I do have it, wouldn't we need > to store the set/show commands in the gdbarch so that they can be > called? A platform-independent set_disassemble_options() (or whatever it is called) command should probably reside in disasm.c, and be installed via (a newly added) _initialize_disasm initializer routine there. To get at the current gdbarch, you can use get_current_arch (). This function should be rarely used, but the one place where it *is* fine is exactly in top-level command implementation routines. > > All the information to build this should be in opcodes, I think. Even > > for "help show disassembler-cpu", it should be possible for gdb to ask > > opcodes to print a description of each possible option, > > since "objdump --help" does it. Bonus points for hooking that to > > a completer for "set disassembler-cpu ". :-) > > The objdump --help output comes from opcodes/ppc-dis.c's > print_ppc_disassembler_options(FILE *stream). I actually tried > to call that from show_disassembler_cpu(), but the "file" pointer > it's passed is of type "struct ui_file *file" which looks to be > a black box, so I'm not sure how I can extract a "FILE *" pointer > out of that. That doesn't work in general; some "ui_file"s are based on FILE *, but not all of them. One way would be to create a memory-buffer based FILE * via fmemopen or open_memstream and pass that to the opcodes routine. However, those routines are probably not available on all systems supported by GDB ... Another option might be to refactor the way disassembler options output is done in opcodes, e.g. by having platform-specific code only provide an array of tuples of option names and explanatory strings, and move the actual printing to common code. Then those arrays could be exported to and reused by GDB. (In particular, there's really no way to do a completer without such information.) > I don't know how to set up a completer and I don't see one. > Do you know of an example in the code I could look at/copy? You need to implement a completer callback and install it for your command via set_cmd_completer. There's a couple of examples to look at, but for something like this where there is a predefined list of available options, you should probably simply use the complete_on_enum helper in your completer, like e.g. done in cp_abi_completer. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com