* <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... @ 2003-05-04 3:12 Andrew Cagney 2003-05-04 3:33 ` Doug Evans ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Andrew Cagney @ 2003-05-04 3:12 UTC (permalink / raw) To: gdb This picks up an old old topic Since MarkK is threatening to get the i386 using the new frame code, now is probably the time to think about where all these frame modules should live: d10v-frame.[hc]: Fills the top-level directory up with more stuff. That got objections when it was last suggested. frame/<cpu>.[hc]: Keeps all the frame code in one directory. This makes it clearer that the code is ment to be frame centric (and not the place to put non-frame stuff). config/<cpu>/frame.[hc]: Keeps the cpu stuff in a single directory. ...: ... ... (there is a long standing task of restructuring the code base, might as well start here :-) Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 3:12 <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, Andrew Cagney @ 2003-05-04 3:33 ` Doug Evans 2003-05-04 4:10 ` Andrew Cagney 2003-05-04 15:44 ` Daniel Jacobowitz 2003-05-04 16:41 ` David Carlton 2 siblings, 1 reply; 10+ messages in thread From: Doug Evans @ 2003-05-04 3:33 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb Andrew Cagney writes: > config/<cpu>/frame.[hc]: > Keeps the cpu stuff in a single directory. Seems like this is a winner though you'd still want to call it <cpu>-frame.c to avoid collisions in multi-arch targeted gdb's. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 3:33 ` Doug Evans @ 2003-05-04 4:10 ` Andrew Cagney 2003-05-04 7:31 ` Doug Evans ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Andrew Cagney @ 2003-05-04 4:10 UTC (permalink / raw) To: Doug Evans; +Cc: gdb > Andrew Cagney writes: > > config/<cpu>/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/<cpu>/*.{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 <cpu> files together. There is the question of where to put more generic unwinders (dwarf2cfi, libunwind, ...) > Seems like this is a winner though you'd still want to call it > <cpu>-frame.c to avoid collisions in multi-arch targeted gdb's. ? Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 4:10 ` Andrew Cagney @ 2003-05-04 7:31 ` Doug Evans 2003-05-04 15:46 ` Daniel Jacobowitz 2003-05-07 18:49 ` Andrew Cagney 2 siblings, 0 replies; 10+ messages in thread From: Doug Evans @ 2003-05-04 7:31 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb Andrew Cagney writes: > config/<cpu>/*.{mt,mh,h} are all > being deleted, so adding files to that directory would make for > confusion. I dunno about confusion. The consistency with gcc and gas is nice. (while gas doesn't have config/<cpu>, neither did gcc until way back when, not that I'm suggesting gas should have config/<cpu>, just that both have config/<something> for target files). If one is going to try to reduce the number of files in the top level dir, to me having all the target specific files in config/<cpu> seems reasonable (and more preferable than having them littered about in the top level directory and various subdirs). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 4:10 ` Andrew Cagney 2003-05-04 7:31 ` Doug Evans @ 2003-05-04 15:46 ` Daniel Jacobowitz 2003-05-04 16:42 ` Andrew Cagney 2003-05-07 18:49 ` Andrew Cagney 2 siblings, 1 reply; 10+ messages in thread From: Daniel Jacobowitz @ 2003-05-04 15:46 UTC (permalink / raw) To: Andrew Cagney; +Cc: Doug Evans, gdb On Sun, May 04, 2003 at 12:10:36AM -0400, Andrew Cagney wrote: > >Andrew Cagney writes: > > > config/<cpu>/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/<cpu>/*.{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 <cpu> 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... > >Seems like this is a winner though you'd still want to call it > ><cpu>-frame.c to avoid collisions in multi-arch targeted gdb's. > > ? For instance, gcc -c normally drops object files in the current directory. 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... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 15:46 ` Daniel Jacobowitz @ 2003-05-04 16:42 ` Andrew Cagney 2003-05-04 18:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cagney @ 2003-05-04 16:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Doug Evans, gdb > On Sun, May 04, 2003 at 12:10:36AM -0400, Andrew Cagney wrote: > >> >Andrew Cagney writes: > >> > > config/<cpu>/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/<cpu>/*.{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 <cpu> 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/<cpu>/* 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 >> ><cpu>-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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 16:42 ` Andrew Cagney @ 2003-05-04 18:25 ` Daniel Jacobowitz 0 siblings, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2003-05-04 18:25 UTC (permalink / raw) To: Andrew Cagney; +Cc: Doug Evans, gdb 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/<cpu>/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/<cpu>/*.{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 <cpu> 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/<cpu>/* 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 4:10 ` Andrew Cagney 2003-05-04 7:31 ` Doug Evans 2003-05-04 15:46 ` Daniel Jacobowitz @ 2003-05-07 18:49 ` Andrew Cagney 2 siblings, 0 replies; 10+ messages in thread From: Andrew Cagney @ 2003-05-07 18:49 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb FYI, the list keeps growing: - generic unwinders (libunwind=-unwind, dwarf2-unwind, ...) - os specific unwinders (some sigtramps, something to handle the evilness recently added to the linux kernel http://sources.redhat.com/ml/gdb/2003-04/msg00153.html, ...) - isa specific unwinders - cross products of the above Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 3:12 <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, Andrew Cagney 2003-05-04 3:33 ` Doug Evans @ 2003-05-04 15:44 ` Daniel Jacobowitz 2003-05-04 16:41 ` David Carlton 2 siblings, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2003-05-04 15:44 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Sat, May 03, 2003 at 11:12:38PM -0400, Andrew Cagney wrote: > This picks up an old old topic > > Since MarkK is threatening to get the i386 using the new frame code, now > is probably the time to think about where all these frame modules should > live: > > d10v-frame.[hc]: > Fills the top-level directory up with more stuff. That got objections > when it was last suggested. > > frame/<cpu>.[hc]: > Keeps all the frame code in one directory. This makes it clearer that > the code is ment to be frame centric (and not the place to put non-frame > stuff). > > config/<cpu>/frame.[hc]: > Keeps the cpu stuff in a single directory. Like I said last time, I'm in favor of config/<cpu>/. Splitting support files for a particular CPU across multiple functional area directories would be annoying, I think. The toplevel directory could do with some pruning. And I don't think it will be especially confusing. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ... 2003-05-04 3:12 <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, Andrew Cagney 2003-05-04 3:33 ` Doug Evans 2003-05-04 15:44 ` Daniel Jacobowitz @ 2003-05-04 16:41 ` David Carlton 2 siblings, 0 replies; 10+ messages in thread From: David Carlton @ 2003-05-04 16:41 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Sat, 03 May 2003 23:12:38 -0400, Andrew Cagney <ac131313@redhat.com> said: > Since MarkK is threatening to get the i386 using the new frame code, > now is probably the time to think about where all these frame modules > should live: > d10v-frame.[hc]: > frame/<cpu>.[hc]: > config/<cpu>/frame.[hc]: I don't care too much, myself, but one difference between the middle and last choices is that the middle choice would generalize to non-cpu-specific stuff; do we want to eventually have, say, a directory containing all the different debug readers? (How many frame modules will there be, anyways?) David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-05-07 18:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-04 3:12 <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, Andrew Cagney 2003-05-04 3:33 ` Doug Evans 2003-05-04 4:10 ` Andrew Cagney 2003-05-04 7:31 ` Doug Evans 2003-05-04 15:46 ` Daniel Jacobowitz 2003-05-04 16:42 ` Andrew Cagney 2003-05-04 18:25 ` Daniel Jacobowitz 2003-05-07 18:49 ` Andrew Cagney 2003-05-04 15:44 ` Daniel Jacobowitz 2003-05-04 16:41 ` David Carlton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).