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

[Andrew Cagney <ac131313@redhat.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...

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