Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix.

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

> It seems like we're adding a bunch of members to struct objfile, and a
> bunch of macros to access them, and a bunch of code to
> default_symfile_offsets to initialize them, for the benefit of
> a new function `sect_index_for_sc' in mdebugread.c.
> 
> It seems like it would be cleaner to simply have some mdebug-specific
> code look up the offsets and fill in a table indexed by mdebug SC
> number, which sect_index_for_sc could then access directly.  That
> would keep the entire change isolated in mdebugread.c, which is the
> only reader that needs all that info.  Does that sound reasonable?
> 
> Peter, I think you're more familiar with the big picture regarding the
> section offset handling than I am, so I'm interested in your comments.

That's what I meant with:

: > I am not sure if adding to sect_index_* and SECT_OFF_* is the way to go in
: > the general version, hiding those in obj_private might be feasible.

We would need a mdebug section index table per objfile, but I am not sure if
obj_private is the right place. As obj_private is currently only used
by HPPA targets, it might be safe.

Using sym_private is dangerous, as explained in the following comment
from mdebugread.c:

/* The pending information is kept for an entire object file, and used
   to be in the sym_private field.  I took it out when I split
   mdebugread from mipsread, because this might not be the only type
   of symbols read from an object file.  Instead, we allocate the
   pending information table when we create the partial symbols, and
   we store a pointer to the single table in each psymtab.  */

Perhaps we could use pst_private for the mdebug section index table pointer,
but then we have to use another temporary global variable (like pending_list),
which I am not very fond of.

I'll come up with a proper RFA if we find a consensus where the mdebug
section indices table should live.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de