From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7915 invoked by alias); 4 May 2003 18:25:52 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7905 invoked from network); 4 May 2003 18:25:52 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 4 May 2003 18:25:52 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19COBf-00029S-00; Sun, 04 May 2003 13:26:11 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19COBH-0003ln-00; Sun, 04 May 2003 14:25:47 -0400 Date: Sun, 04 May 2003 18:25:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Doug Evans , gdb@sources.redhat.com Subject: Re: -frame.c, frame/.c, config//frame.c, ... Message-ID: <20030504182547.GA14441@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Doug Evans , gdb@sources.redhat.com References: <3EB48526.9060104@redhat.com> <16052.35297.269737.92814@casey.transmeta.com> <3EB492BC.3080502@redhat.com> <20030504154654.GC12099@nevyn.them.org> <3EB542D4.6010609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EB542D4.6010609@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00043.txt.bz2 On Sun, May 04, 2003 at 12:41:56PM -0400, Andrew Cagney wrote: > >On Sun, May 04, 2003 at 12:10:36AM -0400, Andrew Cagney wrote: > > > >>>Andrew Cagney writes: > > > >>> > config//frame.[hc]: > >>> > Keeps the cpu stuff in a single directory. > > > >> > >>Some things I forgot to note: > >> > >>This is actually the one I like least. config//*.{mt,mh,h} are all > >>being deleted, so adding files to that directory would make for > >>confusion. Unlike {unwind,frame}/, it isn't clear what the exact > >>interface that the file should be exporting was. On the other hand, it > >>keeps files together. > >> > >>There is the question of where to put more generic unwinders (dwarf2cfi, > >>libunwind, ...) > > > > > >Hmm. For non-cpu-specific files, we have two choices that I can think > >of off the top of my head: > > - Toplevel directory > > - Functional subdirectory, i.e. unwind/ or frame/. I rather like > > that idea... > > This is somewhat at odds with having the CPU files, that implement the > exact same interface, in a separate directory. Hmm, maybe. I guess my preferences would be generic code in the toplevel and cpu code in a config/cpu/ dir. But that may be just because I'm familiar with trees laid out that way. > Having the CPU specific files in one place is nice if the only concern > is hacking on those cpu specific files. However, when hacking cross > architecture (as I'm typically doing), or wanting to examine a > consistent set of examples for a given interface (as someone adding a > new architecture would be doing), then I think having a one stop > [directory] shop is far easier. Having stuff scattered across many and > inconsistent set of directories and files is a straight pain in the bum > - look how often people [me] miss something burried in one of the > config//* files. Honestly, I don't think it makes a lot of difference when hacking cross-architecture. I've done that in GCC from time to time; you have to remember to use grep -r instead of grep, but otherwise it's no more work. You have to do it now anyway, since so much is in tm headers. But this is mostly conjecture too. Don't know how it would work out. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer