Re: [9/10] RFC: remove general_symbol_info::obj_section

[Pedro Alves <palves at redhat dot com>]

On 02/18/2013 08:38 PM, Tom Tromey wrote:
> 
> * stabsread.c was setting the symbol's section.  However, this caused
>   some test failures on HPPA.  It seemed better to me not to set the
>   section and to let fixup_section do its work.

Do you recall specifically why that caused failures?  I'm curious
why that wasn't a problem before this series.

> * fixup_section now has some "fallback" code to try to set the section
>   if it is not found via minsyms.
> 
>   I think this function is fundamentally confused.
> 
>   The comment explains how this is only ever called for un-relocated
>   symbols.  And, the code in this function works on that assumption.
> 
>   However, most of the rest of gdb doesn't work that way.  For instance,
>   I think all the partial symbol readers make relocated symbols and do
>   not set the section.
> 
>   Anyway, the changes I have made shouldn't really affect anything here
>   (well, except perhaps some truly weird situations where a symbol
>   doesn't seem to be in any section, but ... those are already doing
>   something weird.)
> 
>   I'm not really sure what to do here.  I could further change all the
>   symbol readers not to do relocation at read time.  However, I think
>   that is pretty hard.  Anybody have a better idea?

Nope.  But this mystifies me too.  Why wasn't the fallback
necessary before?  Ah, it seems before we'd just happen to end up
with ginfo->section=0 too.  I tried running the testsuite with this:

diff --git c/gdb/symtab.c w/gdb/symtab.c
index 51e920e..6edcef7 100644
--- c/gdb/symtab.c
+++ w/gdb/symtab.c
@@ -1055,6 +1055,8 @@ fixup_section (struct general_symbol_info *ginfo,
              return;
            }
        }
+
+      gdb_assert (0);
     }
 }

And sure enough, that causes a bunch of regressions.

-- 
Pedro Alves