|
Message
From: Gy?rgy 'nog' Jeney<nog@s...>
Date: Wed Jun 29 16:52:26 CEST 2005
Subject: [openrisc] Program execution problems with GDB
> Firstly, sorry for the late reply. I see why it works for me and not you. I
> was testing with gdb-5.0.. If you have a big need to use gdb now, use the 5.0
> version. gdb-5.3 _should_ work aswell, but I just won't have to time to dig
> into this before wednesday. Sorry.
Ok, I had a look at it and it turns out to be a bug in gdb-5.3. What happend
was that on the first command from the user that resulted in running some code
on the target (or1ksim), gdb thought that a new process has been created since
it's internal pid (inferior_pidt) was different to that passed back from
or1k_wait(). When gdb detects that it's now running a new process, it decides
to continue with its execution (don't know why) and as such, the breakpoint set
by the user was reached, but it ended up being ignored! You could work around
it by issueing a run/c/si/ni/etc. command, wait 'till the gdb `froze', interrupt
it and then everything ended up working fine because now inferior_pidt has been
updated to the pidt returned by or1k_wait(). By hacking or1k_wait() to return
inferior_pidt, gdb-5.3 works just like gdb-5.0. I don't know if this is the
proper fix but the remote mips target does the same, so I guess it's the right
thing to do.
Stephan, could you confirm that the attached patch fixes your issue?
nog.
-------------- next part --------------
--- gdb/remote-or1k.c 2004-02-05 15:08:01.000000000 +0100
+++ /home/nog/gdb-5.3/gdb/remote-or1k.c 2005-06-29 16:18:57.000000000 +0200
@@ -1003,7 +1003,7 @@
error("Target in invalid state.");
status->kind = TARGET_WAITKIND_STOPPED;
status->value.sig = TARGET_SIGNAL_TRAP;
- return remote_ptid;
+ return inferior_ptid;
}
if (err)
@@ -1198,7 +1198,7 @@
or1k_read_trace ();
debug ("-wait %i %i\n", pid, or1k_status);
- return remote_ptid;
+ return inferior_ptid;
}
/* Fetch a word from the target board. All memory accesses to the
|
 |
Browse
