Re: gdbarch_init, ABI, and registers

["Ulrich Weigand" <uweigand@de.ibm.com>]

Tim Newsome wrote:

> I've made some progress here.
> 
> gdb does keep track of the description for the current target, and it can
> be retrieved by calling target_current_description(). My problems stemmed
> from the fact that sometimes riscv_gdbarch_init() was called with an info
> structure that did not have the current target description filled out. I
> tracked this down to gdbarch_from_bfd(), which doesn't set
> info.target_desc. set_gdbarch_from_file() does do so (since 2008), and the
> following patch makes everything work for me:
> 
> diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c
> index 2ae3413087..6c84f100af 100644
> --- a/gdb/arch-utils.c
> +++ b/gdb/arch-utils.c
> @@ -600,6 +600,7 @@ gdbarch_from_bfd (bfd *abfd)
>    gdbarch_info_init (&info);
> 
>    info.abfd =3D abfd;
> +  info.target_desc =3D target_current_description ();
>    return gdbarch_find_by_info (info);
>  }
> 
> Does this seem like the right solution? A better one might be to put this
> assignment in gdbarch_info_init(). Or I could just call
> target_current_description() in riscv_arch_init() when no target
> description is passed in. The latter goes against the comment accompanying
> target_current_description(), but it would only be a target-dependent
> change.

No, this doesn't look correct to me.  Note that it is normal during
GDB operation that several different gdbarch objects are in use,
which have somewhat different contents and are used for different
purposes.

In particular, there are gdbarch objects that describe a *target*
(i.e. an inferior GDB is operating on) -- those use target descriptions,
and care about registers etc.

But then there are also gdbarch objects that are used solely when
looking at an *object file*, without involving any connection to a
target -- those don't have target descriptions, and don't care about
registers.

The second type is generated by gdbarch_from_bfd, so those *should*
not get any target description.  This function can be called even
when there is no target currently active at all.

[ As an aside, it would probably be cleaner to actually use two
different data structures for those different purposes in the first
place.  This hasn't been done yet, mostly because it would be a lot
of effort to update all places where platform-specific gdbarch
information is created ... ]


I guess I still haven't quite understood why exactly any of this
is causing a problem for you.  Yes, gdbarch objects returned from
gdbarch_from_bfd will not have correct register info.  But those
objects also should never be used in any context where registers
matter.  Can you be more specific what the actual problem you're
seeing is?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com