Re: [rfa:solib] Handle start-address descriptors

[Kevin Buettner <kevinb@redhat.com>]

On Oct 27,  6:49pm, Andrew Cagney wrote:

> >> +#include "bfd-target.h"
> >> +#include "exec.h"
> > 
> > I'm surprised that you needed to include exec.h.  solib-svr4.c already
> > includes target.h and I would've thought this to be sufficient.  If
> > exec.h isn't needed, please take it out.  (Don't forget to fix Makefile.in.)
> 
> They are both needed.

Okay, I've looked over your patch again and I see why now -- the
address of exec_ops is being passed to exec_entry_point().  (You could
have mentioned this instead of just saying "They are both needed.")

> > Could you add a comment here telling why
> > gdbarch_convert_from_func_ptr_addr() is needed.  Maybe something like
> > this?
> 
> I'll add your comment.

Thanks.

> > Hmm, a possible problem...  What happens when the target uses function
> > descriptors, but not for the exec file's start address?  I'm wondering
> > (ugh) if a separate gdbarch method is required for obtaining the start
> > address.
> 
> Fortunatly a previous patch addressed that problem.  The convert 
> function is only applied to positively identified descriptors.

If I'm not mistaken, this problem has been addressed for ppc64 and
ia64, but not in a generic fashion.  I'm concerned about some other
ABI (for some other architecture) which has function descriptors, but
has no easy way to discriminate between descriptors and code
addresses.  If this ABI specifies that the entry point should refer to
a code address instead of a descriptor, then we need a more
complicated mechanism -- perhaps that separate gdbarch method that I
mentioned earlier.

I suppose we can wait to do something about this problem until it
actually arises.  But... since we've identified a potential problem,
we should at least document it in some appropriate location.  If
the convert_from_func_ptr_addr() method *must* (due to the way it
is used elsewhere) contain a discrimination mechanism, then this
should be mentioned in the documentation.  (BTW, I don't see this
method documented in gdbint.texinfo.)

Kevin