This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Support for Xilinx MicroBlaze
- From: Michael Eager <eager at eagercon dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Eli Zaretskii <eliz at gnu dot org>
- Date: Wed, 14 Oct 2009 10:48:57 -0700
- Subject: Re: [PATCH] Support for Xilinx MicroBlaze
- References: <4ACA9EE8.1040007@eagercon.com> <20091014014655.GL5272@adacore.com>
Joel Brobecker wrote:
2009-10-05 Michael Eager <eager@eagercon.com>
+ /* For sentinel frame, return address is actual PC. For other frames,
+ return address is pc+8. This is a workaround because gcc does not
+ generate correct return address in CIE. */
You do what you have to do, but this is *BAD* idea (IMO). Unless you can
detect the case when GCC generates bad return addresses or not in CIE,
you'll end up having a broken debugger as soon as the compiler gets
fixed. Introducing work arounds for compiler deficiencies is often fine,
but I don't think that this should be done at the cost of proper operation.
Yes, I agree. But ...
I looked at fixing this in gcc a while ago. The translation from rtx to CIE
entry doesn't allow expressing PC+8. If I recall, there was another architecture
(sparc?) which also has a kludge to overcome this deficiency.
Perhaps it is possible to determine whether the CIE contains pc or pc+8
and make the right choice. I'll take a look at this, but I think that
this info is lost long before the return address is used. I really don't
want to put MicroBlaze-specific checks in the target-independent code which
parses the CIE.
If it's not possible to tell whether the CIE is generated correctly or not,
then the situation is that gdb will be unable to backtrace on a code generated
by a fixed compiler, or alternately, if gdb is changed, it will be unable to
backtrace on existing object files. Neither is an acceptable choice.
+ struct regcache *regcache = get_current_regcache ();
This one raised a red flag, as we try to avoid depending on global
variables. But I'm not sure what the kosher way of getting the regcache
would be. I thought there would be method to get the regcache from
a frame, but apparently not. Perhaps the right way is to use
get_thread_arch_regcache (inferior_ptid, gdbarch), but I'm not sure.
I'll ask Ulrich, who knows this area a lot better.
I wasn't able to find a better way to get the regcache either. Perhaps
it's known farther up the call tree, but it isn't passed to the
software single step routine.
On the other hand, I'm not sure that this is functionality is
necessary in the real world. In an embedded environment, I believe
that the target manager (XDM) handles single stepping; on Linux, ptrace
does this. I'll check on this and see if I can eliminate the code.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077