From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7352 invoked by alias); 27 May 2002 22:00:31 -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 7339 invoked from network); 27 May 2002 22:00:30 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.114.42) by sources.redhat.com with SMTP; 27 May 2002 22:00:30 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.11.6/8.11.6) with ESMTP id g4RM0TI01283; Tue, 28 May 2002 00:00:29 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.11.6/8.11.6) id g4RM0T400654; Tue, 28 May 2002 00:00:29 +0200 (CEST) (envelope-from kettenis) From: Mark Kettenis Message-Id: <200205272200.g4RM0T400654@elgar.kettenis.dyndns.org> To: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] Moving x86-64 configuration to separate directory Date: Mon, 27 May 2002 15:41:00 -0000 In-Reply-To: Michal Ludvig's message of "Mon, 27 May 2002 16:52:58 +0200" X-SW-Source: 2002-05/txt/msg00955.txt.bz2 Michal Ludvig writes: > Hi, > I'm about to move all x86-64 configuration stuff to a separate > directory. For now it resides in config/i386 but AFAIK this is a relict > of cloning the the files from eachother, not the necessity. > Yet more x86-64 is definitely a different architecture than i386 :-) Is it really? My understanding is that it is comparable to sparc vs. sparc64. Isn't it possiblle to execute normal 32-bit i386 code on the x86_64? In that case, you'd probably want to have a GDB that can handle both. The only way to be able to accomplish that in the near future is seeing them as different variants of the same architecture. In that case you should leave the files where they are now. Incidentally that's what GCC does. If you want these targets to become really seperate, we should consider doing a repository copy of the files to preserve their history. Mark