RFC for: "Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]"

[Joel Brobecker]

> I see a bit problem this function is objfile based and not solib
> based, as the solib order from svr4_current_sos() is completely lost
> here.
> 
> That is if we have two shared libraries with global variable X ld.so
> defines which one gets used depending on their dlopen order.
> 
> so_list_head already has wrong order due to update_solib_list.  Maybe
> update_solib_list should be fixed to keep both so_list_head order and
> also properly ensure matching objfiles order.
> 
> If someone does some add-symbol-file by hand the order gets lost
> anyway.
> 
> Maybe we could ensure just so_list_head order, place this "correct
> order search" to elf_lookup_lib_symbol and fall back to the old
> unfixed objfiles search in arbitrary order to keep add-symbol-file
> working.
> 
> Sure there should be some exceptions for hidden symbols but this
> should be implementable on top of your CONTEXT_OBJFILE being there
> probably for this purpose.  Plus weak symbols.

I just want to make sure that we do not get carried away trying to
implement the perfect solution, because I don't have the time in
the next few weeks to implement it, and I don't even know how to
do that at the moment.

What I am trying to do is to fix the regression that you observed
in the Fortran testsuite, which somewhat also affects all languages
as well.

> > +  if (context_objfile && !(context_objfile->flags & OBJF_MAINLINE))
> > +    {
> > +      stop = cb (context_objfile, cb_data);
> > +      if (stop)
> > +	return;
> > +    }
> > +
> > +  ALL_OBJFILES (objfile)
> > +    {
> > +      if (!(objfile->flags & OBJF_MAINLINE) && objfile != context_objfile)
> > +	{
> > +	  stop = cb (objfile, cb_data);
> > +	  if (stop)
> > +	    return;
> > +	}
> > +    }
> > +}
> 
> I do not see why to use the OBJF_MAINLINE exceptions here.  I see the
> correct order is just the most simple ALL_OBJFILES loop.

You have to start with the MAINLINE objfiles first, as you demonstrated
with your Fortran program.

What the code above does, in practice, is trying to go through
the ALL_OBJFILES list in the same order as before, except that
we try the "context" objfile file first.  But, to make things
even more interesting, having a "context" objfile does not mean
that it should be checked ahead of any MAINLINE objfile, because
otherwise we break your Fortran test.  Another way of expressing
the intent of my patch is to say: Try the "context" objfile first,
unless it's not a MAINLINE objfile, in which case we try the
MAINLINE objfiles, and then our "context" objfile.

> Maybe you could re-state the case you were trying to fix as your testcase
> 	gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.]
> 	http://sourceware.org/ml/gdb-patches/2012-05/msg00692.html
> is wrong.

Actually, I prefer target-dependent, since I showed that it is not
wrong for x86-windows.

I definitely feel like I've opened a can of worms that I will not have
time and energy to fix (actual linking behavior is target dependent,
and getting the correct search order is also target dependent). This
was also meant as a cheap improvement while I work on extending the
expression parser(s) [I plan on enhancing C and Ada only, not the
other languages]

So, we have two options, at this point:

  (1) Revert my original patch;

  (2) Enhance the heuristics in my patch. This second patch is an
      attempt at this.

I think it would be a loss to revert, but if we cannot converge on
the heuristics for the search, then we'll just go to the previous
search order (which may also be arbitrary in some ways).

In the end, I think the current heuristics are not perfect but more
helpful in some situations, without hopefully be worse for some
other situations. If we can't agree on that, then I think the best
option at this point is to revert my patch, as it obviously had
some unintended and unwanted side effects.

Which way do we want to go?

-- 
Joel

PS: Just a reminder that we are also potentially one week away from
    branching.