From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6686 invoked by alias); 17 May 2002 18:31:46 -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 6666 invoked from network); 17 May 2002 18:31:43 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 17 May 2002 18:31:43 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id EF20D9869; Fri, 17 May 2002 11:31:42 -0700 (PDT) Date: Fri, 17 May 2002 11:31:00 -0000 From: Jason R Thorpe To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Generic OS ABI handling Message-ID: <20020517113142.B14437@dr-evil.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Eli Zaretskii , gdb-patches@sources.redhat.com References: <20020513120839.X3435@dr-evil.shagadelic.org> <15588.11053.545829.689213@localhost.redhat.com> <20020516151705.Y4613@dr-evil.shagadelic.org> <3CE4342B.10803@cygnus.com> <20020516154139.Z4613@dr-evil.shagadelic.org> <3CE4392B.4070009@cygnus.com> <20020516161130.A4613@dr-evil.shagadelic.org> <20020516195255.G4613@dr-evil.shagadelic.org> <2561-Fri17May2002110306+0300-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2561-Fri17May2002110306+0300-eliz@is.elta.co.il>; from eliz@is.elta.co.il on Fri, May 17, 2002 at 11:03:07AM +0300 Organization: Wasabi Systems, Inc. X-SW-Source: 2002-05/txt/msg00742.txt.bz2 On Fri, May 17, 2002 at 11:03:07AM +0300, Eli Zaretskii wrote: > This is approved, but see some minor comments below. Ok, I'll post another patch shortly with the doc changes and ARM changes... > > +/* This table matches the indices assigned to enum gdb_osabi. Keep > > + them in sync. */ > > Wouldn't it be nice to have those in sync automatically, or at least > have a compiler error if they aren't? Well, there is a run-time error if the last one isn't right (this is like how the signal name table is done). > Do I understand correctly that any target whose ABI is not in this > list will cause the warning below to be issued at run time? > > > + if (osabi == GDB_OSABI_UNKNOWN) > > + { > > + /* Don't complain about not knowing the OS ABI if we don't > > + have an inferior. */ > > + if (info.abfd) > > + fprintf_filtered > > + (gdb_stderr, "GDB doesn't recognize the OS ABI of the inferior. " > > + "Attempting to continue with the default %s settings", > > + bfd_printable_arch_mach (arch_info->arch, arch_info->mach)); > > + return; > > If this warning is to be printed in a normal session, it could get > annoying, I think. Yah, actually, there is a FIXME about that in the SH target code... I've been toying with the idea of having a "nowarn" argument to that function to suppress the warning for an unknown OS ABI. Another option might be to catch "unknown" in target-dependent code before gdbarch_init_osabi() is called and set it to something else. E.g. the i386 target currently assumes an otherwise unrecognized binary is SVR4, and thus might have a bit of code that did: /* Default unrecognized ELF binaries to SVR4. */ if (osabi == GDB_OSABI_UNKNOWN && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour) osabi = GDB_OSABI_SVR4; > Or maybe I just couldn't figure out when is that function called, and > what is the precise meaning of having the `unknown' OS ABI. Could you > please tell that in a few words? The function is called by _gdbarch_init() after it has set up the defaults for the gdbarch. The OS ABI handler is then given a chance to fine-tune the gdbarch (e.g. set up signal trampoline and shared library handing, etc.). If the OS ABI is "unknown", then the gdbarch just gets the defaults, since there was no OS ABI handler to fine-tune them. > It might also be a good idea to tell what header file defines those > values, so that if the docs ever gets out of sync, the actual list > could be looked up. ...patch with doc changes incoming shortly. -- -- Jason R. Thorpe