> 2012-11-24  Daniel Jacobowitz  <dan@codesourcery.com>
> 	    Kazu Hirata  <kazu@codesourcery.com>
> 	    Yao Qi  <yao@codesourcery.com>
> 
> 	* objfiles.c (entry_point_address_query): Move some code ...
> 	(init_entry_point_info): ... here.
> 	* solib-svr4.c (exec_entry_point): Likewise.
> 	* symfile.c (generic_load): Call gdbarch_addr_bits_remove on
> 	the entry address.

Unfortunately, this patch breaks GDB on ia64 (linux and hpux) :-(.
Take any program, and try loading it in GDB:

    (gdb) file hello
    Reading symbols from /[...]/hello...
    zsh: 9462 segmentation fault  /[...]/gdb

What happens is that we've now added a call to
gdbarch_convert_from_func_ptr_addr inside init_entry_point_info,
which is called from syms_from_objfile *before* the objfile's
section_offsets array is allocated.

On ia64, gdbarch_convert_from_func_ptr_addr resolves to
ia64_convert_from_func_ptr_addr, which calls find_pc_section.
This, in turns calls update_section_map, which does a sort
on all sections, where qsort_cmp uses the obj_section_addr
macro:

#define obj_section_addr(s)                                             \
  (bfd_get_section_vma ((s)->objfile->obfd, s->the_bfd_section)         \
   + obj_section_offset (s))

... and obj_section_offset is defined as:

#define obj_section_offset(s)                                           \
  (((s)->objfile->section_offsets)->offsets[(s)->the_bfd_section->index])
                  ^^^^^^^^^^^^^^^^^^

Basically, to resolve whether our pointer is pointing to a descriptor
or not, we need to find its associated section. But to find the section,
we need the section_offsets to be defined.

So, to me, it looks like the attempt at resolving the entry point
is performed too early. And to make things even more fun, there
are cases where we do not allocated section_offsets at all:

  if (objfile->sf == NULL)
    return;     /* No symbols.  */

But the other worrisome element is that most calls to
init_entry_point_info are made from routines used as
the "sym_init" struct sym_fns hook, and this hook is
in fact called, in syms_from_objfile, before the section_offsets
table is allocated.

Since syms_from_objfile is calling init_entry_point_info,
it seems to me that the call to init_entry_point_info in
the "sym_init" hooks are redundant, and could be removed,
clearing one hurdle.

The other hurdle is making sure that init_entry_point_info
is called *after* the section offsets have been allocated.
Which means we need to make sure that we always allocate
some, including in the case where no symbols are found.
This must also become a documented invariant.

Attached is a prototype that seems to work on ia64-linux.
I've only tested it against our testsuite for now, but it will
need to be tested with the official testsuite on GNU/Linux,
as well as on Darwin, AiX, and maybe Windows (although,
I think the changes removing the calls to init_entry_point_info
should be fine).

Note that there is a second call to init_entry_point_info,
this time inside reread_symbols, but this one should be fine.

This patch also begs the question whether we might want to
move init_entry_point_info to objfiles.c and make it static.

Thoughts?

-- 
Joel