From: Miles Bader <miles@lsi.nec.co.jp>
To: Andrew Cagney <ac131313@redhat.com>
Cc: uclinux-dev@uclinux.org, gdb@sources.redhat.com
Subject: Re: gdbserver relocation?
Date: Tue, 04 Mar 2003 02:28:00 -0000 [thread overview]
Message-ID: <buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp> (raw)
In-Reply-To: <3E5A3E20.5040706@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
Andrew Cagney <ac131313@redhat.com> writes:
> I suspect you want to send something back using qOffsets.
Yes, that's exactly what I needed.
What do you think of the following patch (I added the `handle_query'
target callback, and then provided a linux-low.c implementation)?
-Miles
Patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gdb-5.3-qoffsets-20030304.patch --]
[-- Type: text/x-patch, Size: 3424 bytes --]
2003-03-04 Miles Bader <miles@gnu.org>
* target.h (struct target_ops): Add `handle_query' op.
* server.c (handle_query): If target has a handle_query op, try
to use it first.
* linux-low.c (linux_handle_query): New function.
(linux_target_ops): Refer to it.
diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/target.h gdb-5.3/gdb/gdbserver/target.h
--- gdb-5.3.orig/gdb/gdbserver/target.h 2002-08-30 03:50:25.000000000 +0900
+++ gdb-5.3/gdb/gdbserver/target.h 2003-03-04 10:41:49.000000000 +0900
@@ -104,6 +104,11 @@
symbols. */
void (*look_up_symbols) (void);
+
+ /* If non-zero, handle a `q' op from gdb, updating OWN_BUF with the result.
+ Should return 1 if the op was handled, otherwise 0. */
+
+ int (*handle_query) (char *own_buf);
};
extern struct target_ops *the_target;
diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/server.c gdb-5.3/gdb/gdbserver/server.c
--- gdb-5.3.orig/gdb/gdbserver/server.c 2002-08-30 03:50:25.000000000 +0900
+++ gdb-5.3/gdb/gdbserver/server.c 2003-03-04 10:43:12.000000000 +0900
@@ -88,6 +88,10 @@
{
static struct inferior_list_entry *thread_ptr;
+ /* First see if the target-specific code wants to deal with this. */
+ if (the_target->handle_query && (*the_target->handle_query) (own_buf))
+ return;
+
if (strcmp ("qSymbol::", own_buf) == 0)
{
if (the_target->look_up_symbols != NULL)
diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/linux-low.c gdb-5.3/gdb/gdbserver/linux-low.c
--- gdb-5.3.orig/gdb/gdbserver/linux-low.c 2002-11-18 09:40:01.000000000 +0900
+++ gdb-5.3/gdb/gdbserver/linux-low.c 2003-03-04 11:15:14.000000000 +0900
@@ -1228,6 +1229,49 @@
#endif
}
+/* Some linux-specific handling for extended 'q' packets. */
+static int
+linux_handle_query (char *own_buf)
+{
+#if defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) && defined(PT_TEXT_LEN)
+ /* Under uClinux, programs are loaded at non-zero offsets, which we need
+ to tell gdb about. */
+ if (strcmp ("qOffsets", own_buf) == 0)
+ {
+ unsigned long text, text_len, real_data;
+ int pid = get_thread_process (current_inferior)->head.id;
+
+ errno = 0;
+
+ text = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_ADDR, 0);
+ text_len = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_LEN, 0);
+ real_data = ptrace (PTRACE_PEEKUSER, pid, (long)PT_DATA_ADDR, 0);
+
+ if (errno == 0)
+ {
+ /* Both text and data offsets produced at compile-time (and so
+ used by gdb) are relative to the beginning of the program,
+ with the data segment immediately following the text segment.
+ However, the actual runtime layout in memory may put the data
+ somewhere else, so when we send gdb a data base-address, we
+ use the real data base address and subtract the compile-time
+ data base-address from it (which is just the length of the
+ text segment). BSS immediately follows data in both cases. */
+ unsigned long data = real_data - text_len;
+ unsigned long bss = data;
+ sprintf (own_buf, "Text=%lx;Data=%lx;Bss=%lx", text, data, bss);
+ }
+ else
+ sprintf (own_buf, "ENN");
+
+ return 1;
+ }
+#endif
+
+ /* Something we don't handle. */
+ return 0;
+}
+
\f
static struct target_ops linux_target_ops = {
linux_create_inferior,
@@ -1241,6 +1285,7 @@
linux_read_memory,
linux_write_memory,
linux_look_up_symbols,
+ linux_handle_query
};
static void
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
--
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff
next prev parent reply other threads:[~2003-03-04 2:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-24 8:29 Miles Bader
2003-02-24 14:28 ` Daniel Jacobowitz
2003-02-24 15:26 ` Miles Bader
2003-02-24 15:43 ` Andrew Cagney
2003-03-04 2:28 ` Miles Bader [this message]
2003-03-04 3:03 ` Daniel Jacobowitz
2003-03-04 3:42 ` Miles Bader
2003-03-04 7:25 ` [uClinux-dev] " Greg Ungerer
2003-03-04 16:29 ` Andrew Cagney
2003-02-24 15:50 ` Daniel Jacobowitz
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=buoheaj3ly5.fsf@mcspd15.ucom.lsi.nec.co.jp \
--to=miles@lsi.nec.co.jp \
--cc=ac131313@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=miles@gnu.org \
--cc=uclinux-dev@uclinux.org \
/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