Re: [patch] Fix uninitialized section index internal error

[Joel Brobecker <brobecker@ACT-Europe.FR>]

Hi Elena,

  I finally had some time to look at the problem we encounter on Tru64
5.1... It's been a long sime since we last discussed this, so here is
a pointer to the original message:

    http://sources.redhat.com/ml/gdb-patches/2001-05/msg00187.html

  I can actually reproduce the internal error with an empty program
without needing to link in libmach.so...

  So, I modified mdebugread.c to separate the handling of symbols
located in the BSS section and the symbols located in the SBSS section,
just as you suggested. I thought that would make the internal-error
disappear, but they did not :-(.

  After investigating a bit more, I found that the linker creates a
certain number of special symbols, such as _ebss, or _fdata for
instance. The Compacq documentation says that all these symbols are
labels. These labels are used as adresses to mark the begining or the
end of a particular part of the an object file. For instance, _ebss
marks the end of the .bss section.

  The "trick" that confuses gdb in our example is that the symbol
table in the executable contains an entry for the "_ebss" symbol, which
storage class is scBss (and I verified this with the native odump
utility). However, the .bss section does not exist! This is not the only
symbol that is causing trouble, others are in a similar case. I noticed
that the problem arrises with the .data section when we try to load the
symbols of /usr/shlib/libm.so, for instance.

  So it appears that having a symbol referencing a section does not
necessarily means that this section actually exists, not for Label
symbols. I'm not sure how to fix this in GDB. I can see several options.

The solution that seems the most reasonable to me is to check whether
the section exists before making the address of the Label symbol relative to
the section start address. Otherwise, if the symbol refers to a
non-existent section, then keep the address as-is and set the storage
class to "unknown". This seems a bit "hacky" to me, because we are
not being very consistant on how we consider the address of the label
(relative or not relative, that is the question).

Another approach, which has the merit of simplifying the code (maybe
a bit too much) is to say: all label addresses are absolute, and we
don't really care which section they are refering to. So the whole
stLabel case code-section collapses to the following line:
   
   ms_type = mst_unknown;
   /* value is already set to ext_in->asym.value */

I find this approach quite attractive, but I am afraid that it might be
a bit too simplistic to be correct...

Let me know what you think,
Thanks.
-- 
Joel