This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: gdb/targets
- To: Fernando Nasser <fnasser at redhat dot com>
- Subject: Re: RFC: gdb/targets
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sun, 25 Mar 2001 14:00:04 -0500
- Cc: gdb at sources dot redhat dot com
- References: <3ABCF2F6.1E031E77@redhat.com>
Fernando Nasser wrote:
>
> It is annoying to work with the gdb directory with the number of files
> that it has today. Andrew said that, in the future, we will have a
> series of subdirectories.
>
> While this does not occur, I was looking for some immediate relief and I
> noticed that we have a class with a good number of files with clear
> separation that we could separate right now.
Can I suggest leaving this until after 5.1 as part of a proper
restructuring. If nothing else it is going to be easier since, at that
point, a heap of code will simply be deleted.
> As you know, GDB has a core part of the code that talks to several
> "targets" that implement operations of the "target vector". I propose
> that we move these files (I volunteer) to a gdb/targets subdirectory
> (please see the list of files below).
> My only doubt is where we should keep the target.c file itself, or even
> the target.h file (which defines the target vector proper). Should they
> go in the subdirectory or stay at the top level GDB directory?
In a way, moving these these files at this point is a bit like
re-aranging the deck chairs on the titanic. The current target vector
has some serious design limitations. I'd really rather see effort being
put into fixing the fundamental design.
Imagine a young child with access to: a loaf of bread, a knife, random
spreads (vegemite, peanut paste, fritz and even ``jelly''), and finally
your favorite book. You can be 99% certain that the child will first:
build a tidy stack of sandwiches; and second: carefully position that
stack on the, floor put your book on top of it, and then sit on it ...
That flattened mess, that was once a stack, is what GDB's target vector
ends up looking like :-)
Andrew