[PATCH] solib_global_lookup: Fetch arch from objfile.

[PATCH] solib_global_lookup: Fetch arch from objfile.

[Doug Evans]

Hi.

solib_global_lookup should be using the objfile's arch,
not fetching it from global state.

Regression tested on amd64-linux.

2014-10-31  Doug Evans  <xdje42@gmail.com>

	* objfiles.c (get_objfile_arch): Constify.
	* objfiles.h (get_objfile_arch): Update prototype.
	* solib.c (solib_global_lookup): Fetch arch from objfile,
	not target_gdbarch.

diff --git a/gdb/objfiles.c b/gdb/objfiles.c
index 2a5c15f..38a365c 100644
--- a/gdb/objfiles.c
+++ b/gdb/objfiles.c
@@ -366,8 +366,9 @@ allocate_objfile (bfd *abfd, const char *name, int flags)
 }
 
 /* Retrieve the gdbarch associated with OBJFILE.  */
+
 struct gdbarch *
-get_objfile_arch (struct objfile *objfile)
+get_objfile_arch (const struct objfile *objfile)
 {
   return objfile->per_bfd->gdbarch;
 }
diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index 57a94e1..af80c0c 100644
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -465,7 +465,7 @@ struct objfile
 
 extern struct objfile *allocate_objfile (bfd *, const char *name, int);
 
-extern struct gdbarch *get_objfile_arch (struct objfile *);
+extern struct gdbarch *get_objfile_arch (const struct objfile *);
 
 extern int entry_point_address_query (CORE_ADDR *entry_p);
 
diff --git a/gdb/solib.c b/gdb/solib.c
index 41250a2..6260dac 100644
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -1408,7 +1408,7 @@ solib_global_lookup (const struct objfile *objfile,
 		     const char *name,
 		     const domain_enum domain)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (get_objfile_arch (objfile));
 
   if (ops->lookup_lib_global_symbol != NULL)
     return ops->lookup_lib_global_symbol (objfile, name, domain);

Re: [PATCH] solib_global_lookup: Fetch arch from objfile.

[Doug Evans]

Doug Evans <xdje42@gmail.com> writes:
> Hi.
>
> solib_global_lookup should be using the objfile's arch,
> not fetching it from global state.
>
> Regression tested on amd64-linux.
>
> 2014-10-31  Doug Evans  <xdje42@gmail.com>
>
> 	* objfiles.c (get_objfile_arch): Constify.
> 	* objfiles.h (get_objfile_arch): Update prototype.
> 	* solib.c (solib_global_lookup): Fetch arch from objfile,
> 	not target_gdbarch.

Committed.

Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)

[Ulrich Weigand]

Doug Evans wrote:

> solib_global_lookup should be using the objfile's arch,
> not fetching it from global state.
> 
> Regression tested on amd64-linux.
> 
> 2014-10-31  Doug Evans  <xdje42@gmail.com>
> 
> 	* objfiles.c (get_objfile_arch): Constify.
> 	* objfiles.h (get_objfile_arch): Update prototype.
> 	* solib.c (solib_global_lookup): Fetch arch from objfile,
> 	not target_gdbarch.

This also causes a regression in Cell multi-arch debugging.

The problem is that solib_ops are really only installed for
the main target_gdbarch.  As opposed to many other things,
there is just a single solib_ops vector, intended to describe
the dynamic loader in use on the inferior.  While it can make
sense to have multiple loaders when debugging different
inferiors, within a single inferior we support only one.

The solib_global_lookup routine was intended to describe the
operation of that (single) dynamic loader, so that GDB's symbol
lookup can achieve the same result as the native dynamic loader
would.  That's why we added that routine to the solib_ops.

On Cell, the dynamic loader runs on the PowerPC side (which
is was target_gdbarch () returns), and so we installed the
solib_ops there.  The Cell implementation of solib_global_lookup
then handles both PowerPC and SPU objects.

However, after your patch, this implementation now never gets
called for SPU objects any more, which means the special
lookup rules are no longer implemented.

Simply reverting this patch makes everything work for me again.
Was there any specific reason why you made this change in the
first place?  Does this fix any specific problem?

Bye,
Ulrich

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

Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)

[Doug Evans]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> Doug Evans wrote:
>
>> solib_global_lookup should be using the objfile's arch,
>> not fetching it from global state.
>> 
>> Regression tested on amd64-linux.
>> 
>> 2014-10-31  Doug Evans  <xdje42@gmail.com>
>> 
>> 	* objfiles.c (get_objfile_arch): Constify.
>> 	* objfiles.h (get_objfile_arch): Update prototype.
>> 	* solib.c (solib_global_lookup): Fetch arch from objfile,
>> 	not target_gdbarch.
>
> This also causes a regression in Cell multi-arch debugging.
>
> The problem is that solib_ops are really only installed for
> the main target_gdbarch.  As opposed to many other things,
> there is just a single solib_ops vector, intended to describe
> the dynamic loader in use on the inferior.  While it can make
> sense to have multiple loaders when debugging different
> inferiors, within a single inferior we support only one.
>
> The solib_global_lookup routine was intended to describe the
> operation of that (single) dynamic loader, so that GDB's symbol
> lookup can achieve the same result as the native dynamic loader
> would.  That's why we added that routine to the solib_ops.
>
> On Cell, the dynamic loader runs on the PowerPC side (which
> is was target_gdbarch () returns), and so we installed the
> solib_ops there.  The Cell implementation of solib_global_lookup
> then handles both PowerPC and SPU objects.
>
> However, after your patch, this implementation now never gets
> called for SPU objects any more, which means the special
> lookup rules are no longer implemented.
>
> Simply reverting this patch makes everything work for me again.
> Was there any specific reason why you made this change in the
> first place?  Does this fix any specific problem?

Interesting.
I wasn't aware of this treatment of gdbarch.
Sounds like another API cleanup is in order, it's pretty subtle.

So I get now that there is an inferior gdbarch that is potentially
distinct from whatever gdbarch one has at hand (e.g., an objfile's),
[that's the easy part]
and that certain API calls *have* to use the inferior gdbarch.
[that's the subtle part]

One question that comes to mind is why don't the other gdbarches
in the system, e.g., the spu's, delegate these calls to its "parent" gdbarch?
Any design that requires global state like this is suboptimal,
and I'd like to see gdb move away from it wherever possible.
[Here we have a gdbarch from the objfile, but we can't use it.]

Another thought that comes to mind is, if we don't want "child gdbarches"
to delegate to "parent gdbarches" (and I haven't decided myself), then
another way to go is to use different types.
E.g., inferior_gdbarch and gdbarch.
[I might name inferior_gdbarch differently, depending on what API calls
it contains, but this would be another way to avoid potential confusion
over what the correct gdbarch to use is in any particular situation.]

I'm ok with reverting this particular part of the patch,
though it'd be helpful to add a comment explaining
why things are the way they are.

Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)

[Ulrich Weigand]

Doug Evans wrote:

> So I get now that there is an inferior gdbarch that is potentially
> distinct from whatever gdbarch one has at hand (e.g., an objfile's),
> [that's the easy part]
> and that certain API calls *have* to use the inferior gdbarch.
> [that's the subtle part]
> 
> One question that comes to mind is why don't the other gdbarches
> in the system, e.g., the spu's, delegate these calls to its "parent" gdbarch?
> Any design that requires global state like this is suboptimal,
> and I'd like to see gdb move away from it wherever possible.
> [Here we have a gdbarch from the objfile, but we can't use it.]
> 
> Another thought that comes to mind is, if we don't want "child gdbarches"
> to delegate to "parent gdbarches" (and I haven't decided myself), then
> another way to go is to use different types.
> E.g., inferior_gdbarch and gdbarch.
> [I might name inferior_gdbarch differently, depending on what API calls
> it contains, but this would be another way to avoid potential confusion
> over what the correct gdbarch to use is in any particular situation.]

Well, it's a bit more subtle, even.  First of all, there's two distinct
"classes" of gdbarch structures, corresponding to the "symbol side" and
the "target side" of GDB, respectively.  On the symbol side, we have all
the information that is determined solely by looking at an objfile and
well-known ABI conventions.  On the target side, we have in addition all
the information that is determined by the running target (e.g. register
names etc.).  For more details, see here:
https://sourceware.org/ml/gdb-patches/2007-12/msg00142.html

The "symbol side" gdbarch is used as the architecture associated with
objfiles, types, and symbols.  The "target side" gdbarch is used as
the architecture associated with the inferior as a whole, with a
thread, or with a stack frame.

Now, in both symbol side and target side, there may be different
architecture instances active during a single debug session.  In
particular, during Cell/B.E. debugging, there will be PowerPC
objfiles and SPU objfiles.  In addition, some threads and/or stack
frames will be of PowerPC architecture, and others of SPU architecture.
The main inferior will be of PowerPC architecture (in mixed debugging)
or of SPU architecture (when doing SPU stand-alone debugging).
(With multi-inferior debugging, we may have different main inferior
architectures at the same time as well.)

Now, I tend to agree that there should be some sort of child/parent
relationship between a symbol-side gdbarch and a target-side gdbarch.
Specifically, a target-side gdbarch should *contain* a symbol-side
gdbarch *and additional information*.   However, this should still
apply only to the same basic architecture, i.e. the PowerPC target
gdbarch should include the PowerPC symbol gdbarch, and likewise
for SPU.  [ I originally wanted to implement this as two distinct
data types, but this will require a significant amount of refactoring
work, and in the end I never got around to doing this. ]

But I don't think there should be a direct relationship between
the SPU arch and the PowerPC arch, as you describe above.
Execution may be in a PowerPC frame on an SPU thread running
in a PowerPC inferior ... but there's no relationship between
the architectures as such.  When using any of these, you just
have to know whether you're interested in a property of the
current frame, current thread, or current inferior.

Now, the "target_gdbarch" is a bit of a special case.  It used
to have a distinct semantics: the architecture used at the
target interface level.  (Think of it as the architecture that
defines the contents of the register packets of the remote
gdbserver protocol.)  However, since the remote protocol was
extended to actually support using *multiple* different
architectures, there's no longer a need for target_gdbarch
as a distinct concept.  And in fact, it's now simply defined
as the architecture of the current inferior:

struct gdbarch *
target_gdbarch (void)
{
  return current_inferior ()->gdbarch;
}

I'd be in favor of inlining this function into every user,
and starting to replace "current_inferior" with any given
inferior that we may be actually operating on in these
places.
 
> I'm ok with reverting this particular part of the patch,
> though it'd be helpful to add a comment explaining
> why things are the way they are.

There is a comment in gdbarch.h, but that may not be in
a prominent enough place:

/* The architecture associated with the inferior through the
   connection to the target.

   The architecture vector provides some information that is really a
   property of the inferior, accessed through a particular target:
   ptrace operations; the layout of certain RSP packets; the solib_ops
   vector; etc.  To differentiate architecture accesses to
   per-inferior/target properties from
   per-thread/per-frame/per-objfile properties, accesses to
   per-inferior/target properties should be made through this
   gdbarch.  */

Maybe one way to make this obvious would be to change solib_ops
to take an inferior instead of a gdbarch as argument ...

Bye,
Ulrich

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

Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)

[Doug Evans]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> Doug Evans wrote:
>
>> So I get now that there is an inferior gdbarch that is potentially
>> distinct from whatever gdbarch one has at hand (e.g., an objfile's),
>> [that's the easy part]
>> and that certain API calls *have* to use the inferior gdbarch.
>> [that's the subtle part]
>> 
>> One question that comes to mind is why don't the other gdbarches
>> in the system, e.g., the spu's, delegate these calls to its "parent" gdbarch?
>> Any design that requires global state like this is suboptimal,
>> and I'd like to see gdb move away from it wherever possible.
>> [Here we have a gdbarch from the objfile, but we can't use it.]
>> 
>> Another thought that comes to mind is, if we don't want "child gdbarches"
>> to delegate to "parent gdbarches" (and I haven't decided myself), then
>> another way to go is to use different types.
>> E.g., inferior_gdbarch and gdbarch.
>> [I might name inferior_gdbarch differently, depending on what API calls
>> it contains, but this would be another way to avoid potential confusion
>> over what the correct gdbarch to use is in any particular situation.]
>
> Well, it's a bit more subtle, even.  First of all, there's two distinct
> "classes" of gdbarch structures, corresponding to the "symbol side" and
> the "target side" of GDB, respectively.  On the symbol side, we have all
> the information that is determined solely by looking at an objfile and
> well-known ABI conventions.  On the target side, we have in addition all
> the information that is determined by the running target (e.g. register
> names etc.).  For more details, see here:
> https://sourceware.org/ml/gdb-patches/2007-12/msg00142.html

Thanks for the reference.

> The "symbol side" gdbarch is used as the architecture associated with
> objfiles, types, and symbols.  The "target side" gdbarch is used as
> the architecture associated with the inferior as a whole, with a
> thread, or with a stack frame.
>
> Now, in both symbol side and target side, there may be different
> architecture instances active during a single debug session.  In
> particular, during Cell/B.E. debugging, there will be PowerPC
> objfiles and SPU objfiles.  In addition, some threads and/or stack
> frames will be of PowerPC architecture, and others of SPU architecture.
> The main inferior will be of PowerPC architecture (in mixed debugging)
> or of SPU architecture (when doing SPU stand-alone debugging).
> (With multi-inferior debugging, we may have different main inferior
> architectures at the same time as well.)

This much I get. :-)

> Now, I tend to agree that there should be some sort of child/parent
> relationship between a symbol-side gdbarch and a target-side gdbarch.
> Specifically, a target-side gdbarch should *contain* a symbol-side
> gdbarch *and additional information*.

... and we should make them separate types.

> However, this should still
> apply only to the same basic architecture, i.e. the PowerPC target
> gdbarch should include the PowerPC symbol gdbarch, and likewise
> for SPU.  [ I originally wanted to implement this as two distinct
> data types, but this will require a significant amount of refactoring
> work, and in the end I never got around to doing this. ]

Heh. Good to know.
[And I'm not complaining btw.]

> But I don't think there should be a direct relationship between
> the SPU arch and the PowerPC arch, as you describe above.
> Execution may be in a PowerPC frame on an SPU thread running
> in a PowerPC inferior ... but there's no relationship between
> the architectures as such.  When using any of these, you just
> have to know whether you're interested in a property of the
> current frame, current thread, or current inferior.

Well, I wouldn't read too much into my suggestion.
It was pragmatic and pragmatism has tradeoffs by definition.
[For reference sake, I was envisioning setting up the
hierarchy at runtime when we knew what kind of hierarchy
was actually present. As for *which* architecture to ultimately use
that problem is still up to the user/caller.]

> Now, the "target_gdbarch" is a bit of a special case.  It used
> to have a distinct semantics: the architecture used at the
> target interface level.  (Think of it as the architecture that
> defines the contents of the register packets of the remote
> gdbserver protocol.)  However, since the remote protocol was
> extended to actually support using *multiple* different
> architectures, there's no longer a need for target_gdbarch
> as a distinct concept.  And in fact, it's now simply defined
> as the architecture of the current inferior:
>
> struct gdbarch *
> target_gdbarch (void)
> {
>   return current_inferior ()->gdbarch;
> }
>
> I'd be in favor of inlining this function into every user,
> and starting to replace "current_inferior" with any given
> inferior that we may be actually operating on in these
> places.

I'm all for removal of references to global state (where appropriate)
and passing in the needed context.
IWBN to also clean up the types while we're at it.

>> I'm ok with reverting this particular part of the patch,
>> though it'd be helpful to add a comment explaining
>> why things are the way they are.
>
> There is a comment in gdbarch.h, but that may not be in
> a prominent enough place:
>
> /* The architecture associated with the inferior through the
>    connection to the target.
>
>    The architecture vector provides some information that is really a
>    property of the inferior, accessed through a particular target:
>    ptrace operations; the layout of certain RSP packets; the solib_ops
>    vector; etc.  To differentiate architecture accesses to
>    per-inferior/target properties from
>    per-thread/per-frame/per-objfile properties, accesses to
>    per-inferior/target properties should be made through this
>    gdbarch.  */

Yeah, I found that, but too late.
I was suggesting putting a comment at the call site.

[While putting such comments at all such call sites has the potential to
reduce readability, not improve it (if taken to an extreme :-)); until we
use types/APIs that make the code self-documenting, I like the comments.]

> Maybe one way to make this obvious would be to change solib_ops
> to take an inferior instead of a gdbarch as argument ...

In the particular case of solib_ops it does seem like
gdbarch is the wrong "this/self" parameter.

Thanks.

Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)

[Ulrich Weigand]

Doug Evans wrote:
> > Now, the "target_gdbarch" is a bit of a special case.  It used
> > to have a distinct semantics: the architecture used at the
> > target interface level.  (Think of it as the architecture that
> > defines the contents of the register packets of the remote
> > gdbserver protocol.)  However, since the remote protocol was
> > extended to actually support using *multiple* different
> > architectures, there's no longer a need for target_gdbarch
> > as a distinct concept.  And in fact, it's now simply defined
> > as the architecture of the current inferior:
> >
> > struct gdbarch *
> > target_gdbarch (void)
> > {
> >   return current_inferior ()->gdbarch;
> > }
> >
> > I'd be in favor of inlining this function into every user,
> > and starting to replace "current_inferior" with any given
> > inferior that we may be actually operating on in these
> > places.
> 
> I'm all for removal of references to global state (where appropriate)
> and passing in the needed context.
> IWBN to also clean up the types while we're at it.

Sure.  I had thought of leaving the "gdbarch" name for the target
side (which is where it originated from), and some new name for
the symbol side.  This means there'd be no change here (since this
is and remains all target side).

> > Maybe one way to make this obvious would be to change solib_ops
> > to take an inferior instead of a gdbarch as argument ...
> 
> In the particular case of solib_ops it does seem like
> gdbarch is the wrong "this/self" parameter.

I've checked in the patch to revert your change.

On top of that, I'd now suggest something along the following lines
to implement the above suggestion.

At a later stage, we could then add "inferior" arguments to the
solib routines and push calls to current_inferior up to the callers.

Does this look like a reasonable first step to you?

Bye,
Ulrich


ChangeLog:

	* solib.c (solib_ops): Take "struct inferior *" argument
	instead of "struct gdbarch *".
	(solib_find_1, solib_map_sections, clear_so, free_so,
	update_solib_list, solib_add, solib_keep_data_in_core, clear_solib,
	solib_create_inferior_hook, in_solib_dynsym_resolve_code,
	update_solib_breakpoints, handle_solib_event, reload_shared_libraries,
	solib_global_lookup): Update callers.

diff --git a/gdb/solib.c b/gdb/solib.c
index c46116d..e0e58fb 100644
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -63,9 +63,9 @@ solib_init (struct obstack *obstack)
 }
 
 static const struct target_so_ops *
-solib_ops (struct gdbarch *gdbarch)
+solib_ops (struct inferior *inf)
 {
-  const struct target_so_ops **ops = gdbarch_data (gdbarch, solib_data);
+  const struct target_so_ops **ops = gdbarch_data (inf->gdbarch, solib_data);
 
   return *ops;
 }
@@ -152,7 +152,7 @@ show_solib_search_path (struct ui_file *file, int from_tty,
 static char *
 solib_find_1 (char *in_pathname, int *fd, int is_solib)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
   int found_file = -1;
   char *temp_pathname = NULL;
   const char *fskind = effective_target_file_system_kind ();
@@ -533,7 +533,7 @@ solib_bfd_open (char *pathname)
 static int
 solib_map_sections (struct so_list *so)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
   char *filename;
   struct target_section *p;
   struct cleanup *old_chain;
@@ -605,7 +605,7 @@ solib_map_sections (struct so_list *so)
 static void
 clear_so (struct so_list *so)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   if (so->sections)
     {
@@ -645,7 +645,7 @@ clear_so (struct so_list *so)
 void
 free_so (struct so_list *so)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   clear_so (so);
   ops->free_so (so);
@@ -760,7 +760,7 @@ solib_used (const struct so_list *const known)
 static void
 update_solib_list (int from_tty, struct target_ops *target)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
   struct so_list *inferior = ops->current_sos();
   struct so_list *gdb, **gdb_link;
 
@@ -1035,7 +1035,7 @@ solib_add (const char *pattern, int from_tty,
 
     if (loaded_any_symbols)
       {
-	const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+	const struct target_so_ops *ops = solib_ops (current_inferior ());
 
 	/* Getting new symbols may change our opinion about what is
 	   frameless.  */
@@ -1208,7 +1208,7 @@ solib_name_from_address (struct program_space *pspace, CORE_ADDR address)
 int
 solib_keep_data_in_core (CORE_ADDR vaddr, unsigned long size)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   if (ops->keep_data_in_core)
     return ops->keep_data_in_core (vaddr, size);
@@ -1221,7 +1221,7 @@ solib_keep_data_in_core (CORE_ADDR vaddr, unsigned long size)
 void
 clear_solib (void)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   /* This function is expected to handle ELF shared libraries.  It is
      also used on Solaris, which can run either ELF or a.out binaries
@@ -1268,7 +1268,7 @@ clear_solib (void)
 void
 solib_create_inferior_hook (int from_tty)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   ops->solib_create_inferior_hook (from_tty);
 }
@@ -1279,7 +1279,7 @@ solib_create_inferior_hook (int from_tty)
 int
 in_solib_dynsym_resolve_code (CORE_ADDR pc)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   return ops->in_dynsym_resolve_code (pc);
 }
@@ -1315,7 +1315,7 @@ no_shared_libraries (char *ignored, int from_tty)
 void
 update_solib_breakpoints (void)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   if (ops->update_breakpoints != NULL)
     ops->update_breakpoints ();
@@ -1326,7 +1326,7 @@ update_solib_breakpoints (void)
 void
 handle_solib_event (void)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   if (ops->handle_event != NULL)
     ops->handle_event ();
@@ -1423,7 +1423,7 @@ reload_shared_libraries (char *ignored, int from_tty,
 
   reload_shared_libraries_1 (from_tty);
 
-  ops = solib_ops (target_gdbarch ());
+  ops = solib_ops (current_inferior ());
 
   /* Creating inferior hooks here has two purposes.  First, if we reload 
      shared libraries then the address of solib breakpoint we've computed
@@ -1516,7 +1516,7 @@ solib_global_lookup (struct objfile *objfile,
 		     const char *name,
 		     const domain_enum domain)
 {
-  const struct target_so_ops *ops = solib_ops (target_gdbarch ());
+  const struct target_so_ops *ops = solib_ops (current_inferior ());
 
   if (ops->lookup_lib_global_symbol != NULL)
     return ops->lookup_lib_global_symbol (objfile, name, domain);


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