Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: xdje42@gmail.com (Doug Evans)
Cc: gdb-patches@sourceware.org
Subject: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.)
Date: Thu, 27 Aug 2015 14:03:00 -0000	[thread overview]
Message-ID: <20150827140141.A727539FA@oc7340732750.ibm.com> (raw)
In-Reply-To: <m3tx2jbqpu.fsf@seba.sebabeach.org> from "Doug Evans" at Oct 31, 2014 07:27:09 PM

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


  parent reply	other threads:[~2015-08-27 14:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01  2:28 [PATCH] solib_global_lookup: Fetch arch from objfile Doug Evans
2014-11-07  1:13 ` Doug Evans
2015-08-27 14:03 ` Ulrich Weigand [this message]
2015-08-28  5:33   ` Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.) Doug Evans
2015-08-28 13:38     ` Ulrich Weigand
2015-08-28 16:07       ` Doug Evans
2015-08-28 17:20         ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150827140141.A727539FA@oc7340732750.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=xdje42@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox