symbol readers cleanup?

symbol readers cleanup?

[Elena Zannoni]

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

Re: symbol readers cleanup?

[Andrew Cagney]

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


When you say symtab, do you mean symtab or symtab?  That is the symbol 
table information found in the object file or the symtab structure 
inside of GDB?

Was the splitting of hpread.c into two parts logical or arbitrary?  I 
mean, did it actually achieve anything or are the two halves still 
totally entangled.

Anyway, your call :-)

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


I've several suggestions.  However, given that most of them involve some 
form of physical violence using a rolled up printout of that file, I'd 
better not mention them here :-)

	Andrew

Re: symbol readers cleanup?

[Daniel Berlin]

Elena Zannoni <ezannoni@cygnus.com> writes:

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

Please, do.
mdebugread, for instance, still hasn't changed since before the
interfaces to build partial symbols and  symbol blocks moved into
buildsym.
It still makes them by hand.


> Elena

-- 
"You know how it is when you're reading a book and falling
asleep, you're reading, reading...  And all of a sudden you
notice your eyes are closed?  I'm like that all the time.
"-Steven Wright

Re: symbol readers cleanup?

[Elena Zannoni]

Andrew Cagney writes:
 > > 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.
 > 
 > 
 > When you say symtab, do you mean symtab or symtab?  That is the symbol 
 > table information found in the object file or the symtab structure 
 > inside of GDB?
 > 

Yes, the symtab.

:-)

Seriously, the split was made between the routines that generate a GDB
psymtab, and those that generate a gdb symtab. I.e: hp-psymtab-read.c
has hpread_build_psymtabs() (and aux routines) while hp-symtab-read.c
has hpread_psymtab_to_symtab() (and aux routines).  They both deal
only with dntt debug symbols (I think that's the name for HP's debug
format, I can't recall), reading the object file symbol table.

 > Was the splitting of hpread.c into two parts logical or arbitrary?  I 
 > mean, did it actually achieve anything or are the two halves still 
 > totally entangled.
 > 

Actually the hp functions are quite clean. They are at least self
contained. I don't care if we keep the two halves as separate or if we
keep them in a union file. As long as we don't keep both.

 > Anyway, your call :-)
 > 
 > > And see if I can do something with that awful partial-stab.h file.
 > 
 > 
 > I've several suggestions.  However, given that most of them involve some 
 > form of physical violence using a rolled up printout of that file, I'd 
 > better not mention them here :-)
 > 

Where is sac when you need him [1]? Maybe we can take a poll? The most
creative idea wins. :-) (no, please, don't do that! I am just joking!)


[1] http://sources.redhat.com/ml/gdb/2001-05/msg00196.html

 > 	Andrew

Elena

Re: symbol readers cleanup?

[Jim Blandy]

Elena Zannoni <ezannoni@cygnus.com> writes:
> Mind if I clean up a bit?

It sounds good to me.