This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
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...
> >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