From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13496 invoked by alias); 15 May 2002 09:32:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13482 invoked from network); 15 May 2002 09:32:34 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 15 May 2002 09:32:34 -0000 Received: by fw-cam.cambridge.arm.com; id KAA20272; Wed, 15 May 2002 10:32:33 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma020148; Wed, 15 May 02 10:32:23 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA13610 for ; Wed, 15 May 2002 10:32:22 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA23374; Wed, 15 May 2002 10:32:22 +0100 (BST) Message-Id: <200205150932.KAA23374@cam-mail2.cambridge.arm.com> To: gdb@sources.redhat.com cc: Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Multi-arch and user-control of architecture flags Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 02:32:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00157.txt.bz2 More random thoughts that I thought worth writing down before I forget them... The current way to allow for a user to control some aspect of a target is to add a "set" command so that they can control a flag, for example, the ARM target has set apcs32 true/flase to control whether the debugger should work with the processor in 26-bit mode or 32-bit mode. As we move towards supporting multiple processors in a single GDB this is going to become increasingly confusing if we continue down this line, and it will become very unclear (to the poor user) which options apply to which target. So how feasible would it be to extend the "set" and "show" commands so that they could sub-set the information? For example, to allow set and show or even show to show all variables specific to the target. If this isn't particularly practical, then perhaps we need a new command (tset/tshow?) that provides this. R.