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

[Daniel Jacobowitz <drow at mvista dot com>]

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