Re: [PATCH] Support for Xilinx MicroBlaze

[Michael Eager <eager@eagercon.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