symbol readers cleanup?

[Elena Zannoni <ezannoni@cygnus.com>]

Hi,

I am in the process of trying to clean up the intefaces between the
various modules that deal with reading object file formats, debugging
symbols, and the like.

It seems that gdb has come to a state of really high entropy in this
area (if you thought that wait_for_inferior was mess, try looking at
this code!).

There are files that should deal with object files formats 
dbxread.c -- aout
xcoffread.c -- xcoff
coffread.c -- coff
somread.c -- som
nlmread.c -- NetWare
dstread.c -- Apollo
mipsread.c -- ecoff
os9kread.c -- os9k
elfread.c -- elf

And files that should deal with debug formats:
stabsread.c
mdebugread.c
hpread.c
dwarfread.c
dwarf2read.c

The distinction however is fuzzy. The interfaces are not clean.
Several cases refer to stabs functions even though stab is not the
debug format in use, etc.  Some platform specific files are all self
contained, like nlm and dst.  In all this mess there is partial-stab.h
as well.


Mind if I clean up a bit?

As first step, I would like to get rid of the duplicate files:
hpread.c and the pair hp-psymtab-read.c & hp-symtab-read.c.  These
last two were introduced by the hp merge, and they are just the same
as hpread.c, with a logical split with symtab vs. psymtab generation
routines.  There are a few bug fixes in there as well. These files are
used when the hp compilers are used, and deal with HP's debugging
format only.  Gcc's on Hpux emits stabs, and in this case we call into
the stabs reader.  So, would it be OK if I merge the two back into
hpread.c?

Next I would like to move some functions around to be in the correct
files, and tighten the interfaces a bit. 

And see if I can do something with that awful partial-stab.h file.

Jim, I don't think that this is going to interfere with your
dwarf2read.c quest for order. I will not be changing any algorithms or
anything like that. I just would like to disentangle the various
readers, so that if somebody needs to fix something for one format, it
doesn't end up affecting a billion other unrelated platforms. And so
that patch review is a little more streamlined.

This is going to be a slow process (I have a daytime job as well!),
and I don't want to make any changes before the 5.1 branch (which is
coming up pretty soon anyway).

Elena