Design problem with min sym relocation?

[Joel Brobecker <brobecker@gnat.com>]

This is something I found out a while ago, and forgot to mention it
here. It happens on alpha-osf, but this is probably a general issue.

The current version of GDB used at ACT is based on GDB 5.1.1. We get
an internal error when doing the following on Tru64 4.0f:

        (gdb) file /usr/shlib/libm.so
        Reading symbols from /usr/shlib/libm.so...mdebugread.c:2445:
        gdb-internal-error: sect_index_data not initialized
        
        An internal GDB error was detected.  This may make further
        debugging unreliable.  Quit this debugging session? (y or n)

This is caused by a symbol called "signgam" which is located in the
.sdata section. The problem is that GDB seems to be insisting on
coalescing all .*data sections in the same lot, if I understand
parse_partial_symbols in mdebugread.c correctly:

        else if (SC_IS_DATA (ext_in->asym.sc))
          {
            ms_type = mst_data;
            svalue += ANOFFSET (objfile->section_offsets,
                                SECT_OFF_DATA (objfile));
          }

(SC_IS_DATA matches data, sdata, pdata, etc sections)

I think this code snipet shows 2 problems:
  1. We relocated based on the .data section. In our case, 2e should
     relocate relative to the .sdata section. That would be quite
     easy to fix.
  2. ms_type is set to mst_data. This seems to be later used by
     prim_record_minimal_symbol vis:

       case mst_data:
       case mst_file_data:
         section = SECT_OFF_DATA (objfile);
     
     This would be a bit more difficult to fix without adding new
     enum values for each data section kind.

I tried reproducing this problem on Tru64 5.1a, but this time with no
luck. I checked this symbol, and it is still there, and still in the
.sdata section.  But this time, the shared object has a .data section.
So my bet is that GDB computes temporarily gets away with the problem
this time, but computes an incorrect address for this symbol.

I tried with a more recent version of the code, and the internal error
is gone. I don't know if I should rejoyce or not, as I still see the
piece of code that I pasted above.

This is all based on code inspection (cruelly lacking the time to look
more into the problem), but I think there is still a latent problem
where we compute incorrect addresses for certain symbols located in non
mainstream sections (like in the .sdata instead of the .data section).

I would greatly appreciate your thoughs on the issue. My view is that
we should get rid of these SC_IS_* and SECT_OFF_* macros, add new
mst_* enums (one for each section kind), and add services that
compute the ms_type from the section kind, and compute the section
index of a given ms_type. This would give us something like:

   ms_type = get_ms_type_from_storage_class (ext_in->asym.sc);
   svalue += ANOFFSET (objfile->section_offsets, section_index (ms_type));

in mdebugread.c (should move the big ifs list out of parse_partial_symbols),
and then something like this in prim_record_minimal_symbol():

  section = section_index (ms_type);

At the time when I looked at this, I did not start this conversion
because I thought it might touch a large number of file, which I am always
reluctant to do before getting any feedback, especially when it touches
the current design.
-- 
Joel