[9/10] RFC: remove general_symbol_info::obj_section
Pedro Alves
palves@redhat.com
Wed Apr 3 18:14:00 GMT 2013
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
More information about the Gdb-patches
mailing list