From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sources.redhat.com
Subject: Re: [RFC] Replace deprecated_target_new_objfile_hook by observer?
Date: Wed, 18 Oct 2006 16:29:00 -0000 [thread overview]
Message-ID: <200610181629.k9IGT2ZX000588@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20061017233524.GA18064@nevyn.them.org> from "Daniel Jacobowitz" at Oct 17, 2006 07:35:24 PM
Daniel Jacobowitz wrote:
> There Be Dragons! Note that there is a case where the remote objfile
> hook does _not_ call the next thing on the chain. This is somewhat
> deliberate, in that it's what prevents thread-db from being enabled
> when talking to gdbserver, and somewhat accidental, in that I'm sure it
> wasn't meant to work this way. But we'll need to do some rearranging
> in order to keep the current state of affairs working.
I've run into this in my work on GDB support for the Cell BE (which is
getting a lot closer to a state where we can try to submit it, b.t.w.).
We're working on providing code overlay support for the Cell SPEs, and
to support this in the debugger, I needed to hook into the objfile chain;
I ran into exactly the problem you describe above.
To fix this, I'm currently using this patch, which attempts to express
more directly that linux-thread-db should not be used if the target is
remote:
diff -urN gdb-orig/gdb/linux-thread-db.c gdb-6.5/gdb/linux-thread-db.c
--- gdb-orig/gdb/linux-thread-db.c 2006-05-06 00:42:43.000000000 +0200
+++ gdb-6.5/gdb/linux-thread-db.c 2006-09-25 02:12:11.382901136 +0200
@@ -669,6 +669,10 @@
if (!target_has_execution)
return;
+ /* Don't attempt to use thread_db for remote targets. */
+ if (!target_can_run (¤t_target))
+ return;
+
/* Initialize the structure that identifies the child process. */
proc_handle.pid = GET_PID (inferior_ptid);
diff -urN gdb-orig/gdb/remote.c gdb-6.5/gdb/remote.c
--- gdb-orig/gdb/remote.c 2006-05-05 22:08:45.000000000 +0200
+++ gdb-6.5/gdb/remote.c 2006-09-25 02:12:11.449890952 +0200
@@ -5466,8 +5466,7 @@
remote_check_symbols (objfile);
}
/* Call predecessor on chain, if any. */
- if (remote_new_objfile_chain != 0 &&
- remote_desc == 0)
+ if (remote_new_objfile_chain)
remote_new_objfile_chain (objfile);
}
Does this look reasonable?
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2006-10-18 16:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 23:32 Joel Brobecker
2006-10-17 23:35 ` Daniel Jacobowitz
2006-10-18 0:20 ` Joel Brobecker
2006-10-18 1:38 ` Daniel Jacobowitz
[not found] ` <535BF17A-E776-4DE4-979B-7E6FBA505E31@apple.com>
2006-10-18 17:11 ` Daniel Jacobowitz
2006-10-18 16:29 ` Ulrich Weigand [this message]
2006-10-18 16:43 ` Daniel Jacobowitz
2006-10-19 14:30 ` Joel Brobecker
2006-10-20 0:41 ` [PATCH] " Ulrich Weigand
2006-10-20 0:46 ` Daniel Jacobowitz
2006-10-20 1:09 ` Ulrich Weigand
2007-03-28 18:34 ` Ulrich Weigand
2007-03-28 18:42 ` Joel Brobecker
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=200610181629.k9IGT2ZX000588@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.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