From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6103 invoked by alias); 21 Aug 2002 17:04:01 -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 6089 invoked from network); 21 Aug 2002 17:04:00 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Aug 2002 17:04:00 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 184B83E0B; Wed, 21 Aug 2002 13:03:58 -0400 (EDT) Message-ID: <3D63C7FD.6070009@ges.redhat.com> Date: Wed, 21 Aug 2002 10:04: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: Daniel Jacobowitz Cc: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Don't complain about unknown OSABI References: <3D5FC00D.50001@ges.redhat.com> <20020818154927.GA20358@nevyn.them.org> <3D5FCE6A.9080308@ges.redhat.com> <20020819161543.GA10137@nevyn.them.org> <3D61792B.1020708@ges.redhat.com> <20020820015542.GA12371@nevyn.them.org> <3D626854.1040500@ges.redhat.com> <20020820161127.GA26026@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00663.txt.bz2 > On Tue, Aug 20, 2002 at 12:03:32PM -0400, Andrew Cagney wrote: > >> > >> >>GDB uses ../bfd/config.bfd to find the default architecture. I think >> >>this has made our lives much easier -- gdb's and bfd's defaults match >> >>and we don't have to maintain anything. It really is a ``free lunch'' :-) >> >> >> >>Is there an equivalent for the OS/ABI? If we can pick that default up > >> >>from binutils then we also get that for free. On the other hand if we > >> >>start wiring this stuff into configure.tgt (duplicating ld/gcc) we take >> >>on an additional maintenance task. > >> > >> > >> >Exactly my point. There is no OS/ABI equivalent; BFD doesn't know what >> >it is, and doesn't need to. >> > >> >I'll try to put this together tomorrow. > > > No, I won't. Too much arguing about the interaction with set > architecture that I didn't find in my inbox till after I said that. > I'd be willing to put together a version that didn't do that, leaving > the subtleties for a later hacker, but I expect Andrew wouldn't like > that very much :) :-) There are too many edge cases to leave to later. More examples: Here are more examples: (gdb) thread 1 (gdb) show architecture mips (gdb) show osabi MIPS GNU/Linux (gdb) thread 2 (gdb) show architecture x86 (gdb) show osabi cygwin or even: (gdb) show architecture mips (gdb) show osabi n64 (gdb) up (gdb) show architecture mips (gdb) show osabi o32 (gdb) bt foo at line 10 bar at line 20 (or more bizare, tos in an RPC :-)). In the past people have got around this by using: set/show/info eg info ppc something and in so doing, ducked the multi-arch problem. So I'm guessing: (gdb) set architecture mips OSABI cygwin not applicable to MIPS, use ? (y or n)? but that could create the problem: (gdb) set architecture mips OSABI NS32/NetBSD not applicable to MIPS, use IRIX? (y or n)? n (gdb) set osabi MIPS/GNU/Linux OSABI GNU/Linux not applicable to ns32k architecture. Arrg! One way round it is: (gdb) set architecture mips MIPS/GNU/Linux another would be: (gdb) set osabi MIPS/GNU/Linux Current architecture is NS32K, change to MIPS? (y or n) enjoy, Andrew >> Ah, M'kay :-) >> >> Next question. Given an unbranded mips-elf binary, what should the >> following GDB's do? >> >> gdb >> m68k-linux-gnu-gdb > > > Probably complain, unknown architecture. Yes, I know you mentioned > that one can do a certain amount of debugging with just an ELF-aware > GDB. Not enough that the OSABI ever comes into play, though. > > >> mips-gdb >> linux-gnu-gdb >> elf-gdb > > > These are all exceedingly hypothetical beasts at the moment, so I don't > know quite what you mean by the "triplet"s. > > >> mips-linux-gnu-gdb >> mips-netbsd-gdb > > > Default to Linux, default to NetBSD. > > >> Having the behavour key off the target creates a problem with an >> identical executable behaving differently with different, but similar >> GDBs. I suspect it will encourage people to build different GDB's for >> identical purposes when just a single GDB is needed. > > > That's my point though. I _need_ for a MIPS/Linux GDB to default to > MIPS/Linux if there's a missing branding. That's an ease-of-use, > obviousness-of-use thing. GDB has to accept that its detection > mechanisms are sometimes imperfect. There will be a set osabi command > of some sort, it now seems, so the user could always override if > necessary. > > Just a single GDB is needed. But using the right tool for the task, or > at least a wrapper which sets the right variables for the task... > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer