From: Jean-Rene Peulve <jr.peulve@wanadoo.fr>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: gdb@sources.redhat.com, Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: gdbserver for m68k-uclinux
Date: Tue, 09 May 2006 11:58:00 -0000 [thread overview]
Message-ID: <6.1.0.6.0.20060509114307.00a0e780@pop.wanadoo.fr> (raw)
In-Reply-To: <445F5278.3000900@codesourcery.com>
Hi Nathan,
Oups: I resend this because the previous email was html and got bounced by
gdb@sources.redhat.com
I have been forced to change your patch to make it works.
1) missing return in server.c
2) I also add an fprintf to stderr with the address of the text and data
section to allow the use of add-symbol_file command which requires these
address.
The response to qOffsets being hidden by gdb, I then can get it from the
target console or telnet.
Jean-René Peulvé
Here are my revised patches based on yours:
--- server.c.orig 2006-02-08 20:26:00.000000000 +0100
+++ server.c 2006-05-09 11:07:15.000000000 +0200
@@ -129,6 +129,23 @@
}
}
+ if (the_target->read_offsets != NULL
+ && strcmp ("qOffsets", own_buf) == 0)
+ {
+ CORE_ADDR text, data;
+
+ if (the_target->read_offsets (&text, &data)) {
+ sprintf (own_buf, "Text=%lX;Data=%lX;Bss=%lX",
+ (long)text, (long)data, (long)data);
+ return;
+ }
+ else
+ write_enn (own_buf);
+
+ return;
+ }
+
+
if (the_target->read_auxv != NULL
&& strncmp ("qPart:auxv:read::", own_buf, 17) == 0)
{
--- linux-low.c.orig 2006-05-09 11:21:12.000000000 +0200
+++ linux-low.c 2006-05-09 10:58:55.000000000 +0200
@@ -140,7 +140,11 @@
void *new_process;
int pid;
+#if defined(__UCLIBC__) && !defined(__UCLIBC_HAS_MMU__)
+ pid = vfork ();
+#else
pid = fork ();
+#endif
if (pid < 0)
perror_with_name ("fork");
@@ -896,7 +900,7 @@
if (debug_threads && the_low_target.get_pc != NULL)
{
fprintf (stderr, " ");
- (long) (*the_low_target.get_pc) ();
+ (*the_low_target.get_pc) ();
}
/* If we have pending signals, consume one unless we are trying to reinsert
@@ -1550,6 +1554,52 @@
return 0;
}
+#if defined(__UCLIBC__) && !defined(__UCLIBC_HAS_MMU__)
+#if defined(__mcoldfire__)
+/* These should really be defined in the kernel's ptrace.h header. */
+#define PT_TEXT_ADDR 49*4
+#define PT_DATA_ADDR 50*4
+#define PT_TEXT_END_ADDR 51*4
+#endif
+
+/* Under uClinux, programs are loaded at non-zero offsets, which we need
+ to tell gdb about. */
+
+static int
+linux_read_offsets (CORE_ADDR *text_p, CORE_ADDR *data_p)
+{
+#if defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) &&
defined(PT_TEXT_END_ADDR)
+ unsigned long text, text_end, data;
+ int pid = get_thread_process (current_inferior)->head.id;
+
+ errno = 0;
+
+ text = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_ADDR, 0);
+ text_end = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_END_ADDR, 0);
+ data = ptrace (PTRACE_PEEKUSER, pid, (long)PT_DATA_ADDR, 0);
+
+ fprintf(stderr, "text=%lx data=%lx errno=%d\n", text, data, errno);
+ 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. */
+ *text_p = text;
+ *data_p = data - (text_end - text);
+
+ return 1;
+ }
+#endif
+ return 0;
+}
+#endif
+
static struct target_ops linux_target_ops = {
linux_create_inferior,
linux_attach,
@@ -1569,6 +1619,9 @@
linux_remove_watchpoint,
linux_stopped_by_watchpoint,
linux_stopped_data_address,
+#if defined(__UCLIBC__) && !defined(__UCLIBC_HAS_MMU__)
+ linux_read_offsets,
+#endif
};
static void
next prev parent reply other threads:[~2006-05-09 9:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-08 16:57 Nathan Sidwell
2006-05-09 11:58 ` Jean-Rene Peulve [this message]
2006-05-09 12:19 ` Nathan Sidwell
2006-05-09 12:34 ` Jean-Rene Peulve
2006-05-09 12:39 ` Daniel Jacobowitz
2006-05-09 13:20 ` Daniel Jacobowitz
2006-05-09 14:13 ` Nathan Sidwell
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=6.1.0.6.0.20060509114307.00a0e780@pop.wanadoo.fr \
--to=jr.peulve@wanadoo.fr \
--cc=dan@codesourcery.com \
--cc=gdb@sources.redhat.com \
--cc=nathan@codesourcery.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