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] |
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...
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |