From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1846 invoked by alias); 4 May 2003 16:42:00 -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 1814 invoked from network); 4 May 2003 16:41:58 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 4 May 2003 16:41:58 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DB21C2B2F; Sun, 4 May 2003 12:41:56 -0400 (EDT) Message-ID: <3EB542D4.6010609@redhat.com> Date: Sun, 04 May 2003 16:42:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Doug Evans , gdb@sources.redhat.com Subject: Re: -frame.c, frame/.c, config//frame.c, ... References: <3EB48526.9060104@redhat.com> <16052.35297.269737.92814@casey.transmeta.com> <3EB492BC.3080502@redhat.com> <20030504154654.GC12099@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00042.txt.bz2 > 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. 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. The current technique for adding a new architecture is something like `cp -r; ed`. This leads to the new architecture containing all sorts of redundant junk (cf, s390 ending up with a codestream). Agressive deprecation helps a bit, having areas that clearly only contained code implementing certain functionality might as well. Then again, this is all conjecture. >> >Seems like this is a winner though you'd still want to call it >> >-frame.c to avoid collisions in multi-arch targeted gdb's. > >> >> ? > > > For instance, gcc -c normally drops object files in the current > directory. Ulgh, forgot that. > Makes debugging simpler too. Having multiple files named > frame.c in your debug info is a little confusing. > Again, something GDB could handle better, if we could figure out the > interface... (Hmm, if we had files with the same name, we'd have an incentive to fix it :-) Andrew