Add myself as write after approval maintainer

gdb/ChangeLog:

	* MAINTAINERS (Write After Approval): Add "Andreas From".
Remove const from many struct objfile *

I am just not sure if we should go the route of
        struct objfile * -> const struct objfile *
or the other way of:
        const struct objfile * -> struct objfile *

Normally const adding is better but here I do not see much useful to have any
struct objfile * const and then it just causes pointer compatibility problems.

On Wed, 03 Dec 2014 18:18:44 +0100, Doug Evans wrote:
struct objfile is one case where I've decided to just leave the const
out and not worry about it.

gdb/ChangeLog
2014-12-05  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Remove const from struct objfile *.
	* solib-darwin.c, solib-spu.c, solib-svr4.c, solib.c, solist.h,
	symtab.c, symtab.h: In these files.
Unify lookup_symbol_in_objfile_symtabs

That's right, block_lookup_symbol_primary()'s additional requirement over
block_lookup_symbol() is:
	Function is useful if one iterates all global/static blocks of an
	objfile.

Which is satisfied both in lookup_symbol_in_objfile_symtabs() and in
lookup_global_symbol_from_objfile() thanks to their's ALL_OBJFILE_COMPUNITS.

In fact after reverting that ba715d7fe49c8a59660fbd571b935b29eb7cfbdb above
the lines of code were exactly the same.

So instead of accelerating both lookup_symbol_in_objfile_symtabs() and
lookup_global_symbol_from_objfile() I just accelerated
lookup_symbol_in_objfile_symtabs() and I am proposing to reuse
lookup_symbol_in_objfile_symtabs() in lookup_global_symbol_from_objfile()
instead.  In fact such unification would already save some lines of code even
before the checked-in acceleration patch above.

gdb/ChangeLog
2014-12-05  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* symtab.c (lookup_symbol_in_objfile_symtabs): New declaration.
	(lookup_global_symbol_from_objfile): Call it.
2014-12-05  Steve Ellcey  <sellcey@mips.com>

	* ecoff.c (_bfd_ecoff_slurp_symbol_table): Add cast.
Catch exception in value_rtti_indirect_type

In the situation described in bug 17416 [1], an exception thrown in
value_ind can propagate too far and leave an half-built variable object,
leading to a wrong state. This patch adds a TRY_CATCH to catch it and
makes value_rtti_indirect_type return NULL in that case, meaning
that the type of the pointed object could not be found.

If you want, I can also integrate the test case provided in the bug
description. I just don't know how to name it without giving it a
ridiculously long name such as
mi-var-list-children-with-print-object-on-and-a-null-pointer-to-a-structure-that-contains-a-pointer-to-a-structure.exp.

I tested the change on my machine, Ubuntu 14.10 x86-64.

gdb/Changelog:

	* valops.c (value_rtti_indirect_type): Catch exception thrown by
	value_ind.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17416