This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ...


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]