From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13834 invoked by alias); 5 Feb 2006 20:20:47 -0000 Received: (qmail 13825 invoked by uid 22791); 5 Feb 2006 20:20:46 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 05 Feb 2006 20:20:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F5qN1-0001TF-EE; Sun, 05 Feb 2006 15:20:27 -0500 Date: Sun, 05 Feb 2006 20:20:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Jim Blandy , gdb-patches@sourceware.org Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Message-ID: <20060205202027.GA5574@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Jim Blandy , gdb-patches@sourceware.org References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <20060203233935.GA13238@trixie.casa.cgf.cx> <20060205002710.GC8728@trixie.casa.cgf.cx> <20060205020114.GA25947@nevyn.them.org> <8f2776cb0602042339s5f2fa822md543ee05bed367e1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00102.txt.bz2 On Sun, Feb 05, 2006 at 10:00:24PM +0200, Eli Zaretskii wrote: > > Date: Sat, 4 Feb 2006 23:39:17 -0800 > > From: Jim Blandy > > Cc: gdb-patches@sourceware.org > > > > On 2/4/06, Eli Zaretskii wrote: > > > > Date: Sat, 4 Feb 2006 21:01:14 -0500 > > > > From: Daniel Jacobowitz > > > > > > > > I think that mingw32 hosting support and mingw32 native support can be > > > > treated separately; do you disagree? > > > > > > I do. I think they should be treated together, as having a cross > > > debugger that cannot debug natively is kinda silly. > > > > I don't think it's silly. If you are using Windows as a platform for > > cross-development, you may not even have shelled out the bucks for a > > native compiler. In that situation, why would it be ridiculous to > > have a debugger that, like your compiler, is only useful debugging > > programs on your cross target? > > Reality check: how many other non-embedded platforms have their cross- > and native targets separated? Could you clarify what you mean by this? As far as I can interpret it, the answer is "every". We have three kinds of support. Cross target, native target, and general host. We've labored for years to keep cross target and native target completely separate. General host is normally distributed through all of GDB - except for e.g. the serial files. You never build a debugger with just one; normally you want one from column A, zero or one from column B, and one from column C. In a pure multi-arch world you want one or more from column A, but the other columns are unchanged. > > Also, the kinds of things needed to host GDB on a platform are best > > kept partitioned away from the stuff needed for doing native target > > debugging, simply as a matter of design. It's a simple matter of > > separation of concerns. > > Then please explain why do we compile ser-unix.c with native Unix > targets, and ser-go32.c with the DJGPP native target. I'd call that a perfect example of Jim's point. You don't _need_ ser-unix.c to do native debugging; that's the partitioning at work. It's included as a side effect of the fact that a native target depends on also having a cross target. Thus a native Unix GDB can debug a remote Unix program (and I do this every week). A native DJGPP GDB could also debug a remote DJGPP program (if there were an appropriate remote stub, I don't know). -- Daniel Jacobowitz CodeSourcery