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

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

[Andrew Cagney]

This picks up an old old topic

Since MarkK is threatening to get the i386 using the new frame code, now 
is probably the time to think about where all these frame modules should 
live:

d10v-frame.[hc]:
Fills the top-level directory up with more stuff.  That got objections 
when it was last suggested.

frame/<cpu>.[hc]:
Keeps all the frame code in one directory.  This makes it clearer that 
the code is ment to be frame centric (and not the place to put non-frame 
stuff).

config/<cpu>/frame.[hc]:
Keeps the cpu stuff in a single directory.

...:
... ...

(there is a long standing task of restructuring the code base, might as 
well start here :-)

Andrew

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

[Doug Evans]

Andrew Cagney writes:
 > config/<cpu>/frame.[hc]:
 > Keeps the cpu stuff in a single directory.

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.

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

[Andrew Cagney]

> 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, ...)

> 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.

?

Andrew

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

[Doug Evans]

Andrew Cagney writes:
 > config/<cpu>/*.{mt,mh,h} are all 
 > being deleted, so adding files to that directory would make for 
 > confusion.

I dunno about confusion.
The consistency with gcc and gas is nice.
(while gas doesn't have config/<cpu>, neither did gcc until way back when,
not that I'm suggesting gas should have config/<cpu>, just that
both have config/<something> for target files).

If one is going to try to reduce the number of files in the top level dir,
to me having all the target specific files in config/<cpu>
seems reasonable (and more preferable than having them littered about
in the top level directory and various subdirs).

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

[Daniel Jacobowitz]

On Sat, May 03, 2003 at 11:12:38PM -0400, Andrew Cagney wrote:
> This picks up an old old topic
> 
> Since MarkK is threatening to get the i386 using the new frame code, now 
> is probably the time to think about where all these frame modules should 
> live:
> 
> d10v-frame.[hc]:
> Fills the top-level directory up with more stuff.  That got objections 
> when it was last suggested.
> 
> frame/<cpu>.[hc]:
> Keeps all the frame code in one directory.  This makes it clearer that 
> the code is ment to be frame centric (and not the place to put non-frame 
> stuff).
> 
> config/<cpu>/frame.[hc]:
> Keeps the cpu stuff in a single directory.

Like I said last time, I'm in favor of config/<cpu>/.  Splitting
support files for a particular CPU across multiple functional area
directories would be annoying, I think.  The toplevel directory could
do with some pruning.  And I don't think it will be especially
confusing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

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

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

[David Carlton]

On Sat, 03 May 2003 23:12:38 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Since MarkK is threatening to get the i386 using the new frame code,
> now is probably the time to think about where all these frame modules
> should live:

> d10v-frame.[hc]:
> frame/<cpu>.[hc]:
> config/<cpu>/frame.[hc]:

I don't care too much, myself, but one difference between the middle
and last choices is that the middle choice would generalize to
non-cpu-specific stuff; do we want to eventually have, say, a
directory containing all the different debug readers?  (How many frame
modules will there be, anyways?)

David Carlton
carlton@math.stanford.edu

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

[Andrew Cagney]

> 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

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

[Daniel Jacobowitz]

On Sun, May 04, 2003 at 12:41:56PM -0400, Andrew Cagney wrote:
> >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.

Hmm, maybe.  I guess my preferences would be generic code in the
toplevel and cpu code in a config/cpu/ dir.  But that may be just
because I'm familiar with trees laid out that way.

> 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.

Honestly, I don't think it makes a lot of difference when hacking
cross-architecture.  I've done that in GCC from time to time; you have
to remember to use grep -r instead of grep, but otherwise it's no more
work.

You have to do it now anyway, since so much is in tm headers.

But this is mostly conjecture too.  Don't know how it would work out.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

FYI, the list keeps growing:

- generic unwinders (libunwind=-unwind, dwarf2-unwind, ...)
- os specific unwinders (some sigtramps, something to handle the 
evilness recently added to the linux kernel 
http://sources.redhat.com/ml/gdb/2003-04/msg00153.html, ...)
- isa specific unwinders
- cross products of the above

Andrew