From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31229 invoked by alias); 19 Aug 2002 22:31:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31220 invoked from network); 19 Aug 2002 22:31:57 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 19 Aug 2002 22:31:57 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D97283DC6; Mon, 19 Aug 2002 18:31:54 -0400 (EDT) Message-ID: <3D6171DA.7000100@ges.redhat.com> Date: Mon, 19 Aug 2002 15:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Posnjak Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] set osabi command References: <1029446386.30623.13.camel@klada.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00561.txt.bz2 > Hi, > > This patch adds a set osabi command that it used to override the > automatic osabi detection. This is needed for some libary that don't > provide the .note.ABI-tag and the auto detection fails. Thanks! While the command works, I think it can be improved upon. Have a look at the existing ``set architecture'' command. For instance: (gdb) set debug architecture 1 (gdb) set architecture ... a list of architectures ... (gdb) set architecture ... gdb will immediatly change architecture updating everthing ... (gdb) set architecture ... and error message should appear and the architecture doesn't change ... (gdb) set architecture auto ... gdb's architecture is determined by the target ... I think a ``set osabi'' command should be similar in that it always and immediatly has an effect. It gets complex though because the user could enter a sequence like: (gdb) set architecture arm ... architecture forced to arm ... (gdb) set osabi arm_eabi_v1 ... osabi forced to arm_eabi_v1 (gdb) set architecture mips ... architecture forced to mips, what should happen to the OSABI? It can't remain arm_eabi_v1 ... Idea's? > +static char *osabi_set_val = NULL; > + > +enum gdb_osabi > +gdbarch_osabi_var_set () > +{ FYI, it is important that the OSABI not be hardwired in this way. > + if (strcmp(osabi_set_val, "SVR4") == 0) > + return GDB_OSABI_SVR4; > + c = add_set_cmd ("osabi", class_support, var_string, > + (char *) &osabi_set_val, "Set the osabi. Posible targets are: linux, > + hurd, irix, freebsd_aout, freebsd_elf, netbsd_aout, netbsd_aout, > + netbsd_elf, OSF1, SVR4, solaris, wince, netware, go32, arm_apcs, > + arm_eabi_v1, arm_eabi_v2, lynxos", &setlist); > + add_show_from_set (c, &showlist); > + set_cmd_completer (c, filename_completer); > + Have a look at the add_set_enum() command. Andrew