Design problem with min sym relocation?

[Elena Zannoni]

Joel Brobecker writes:
 > 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:

Yes. I remember looking at another similar problem in mdebugread.c for
which the solution was to split SC_IS_BSS and add a new, more
precise SC_IS_SBSS.

[goes look....hey it was you! :)]
http://sources.redhat.com/ml/gdb-patches/2001-06/msg00244.html

Would a similar approach help in this case?

Definitely the SECT_OFF should eventually go. I guess I can call that a
pipe-dream.

Elena


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