Re: [PATCH] Support for Xilinx MicroBlaze

[Michael Eager <eager@eagercon.com>]

Joel Brobecker wrote:
>> I'm just as happy to leave this problem unfixed.  Gcc generates an
>> incorrect CIE entry, which is philosophically not a good thing.
>> But fixing this causes far more problems than it solves.
> 
> One of the things that we perhaps didn't consider is debugging
> code compiled with a compiler other than GCC... Not sure if one
> even exists, though, but that compiler might be generating correct
> debugging info, which would trigger the "bug" in GDB.

There's no other compiler for MicroBlaze.  (I was going to mention
this hypothetical situation, but this has very low probability
of ever being a real concern.)

> Anyway, if "GCC" is unwilling to fix the problem, then GDB has to do
> its best. It's disappointing when that happens, but it's not the first
> time we introduce work-arounds. This one is a little harder to accept
> because it causes GDB to malfunction in case of correct debugging info.
> But it's still better this way, in practice.

It's not so much that GCC is unwilling to fix the problem.  If
I wanted to, I could extend the CIE generation code and modify
the MicroBlaze-specific code in both GCC and GDB.  This would
break debugging existing programs and libraries with the new gdb
as well as break debugging newly compiled code with an old gdb.

(There are ways that this might be synchronized with Xilinx's
release of tool chains to their customers, but I'd be very
reluctant to recommend that a new tool chain be incompatible
with older tool chains unless there was a very compelling reason.)

If anyone can suggest a reasonable way to identify whether the
CIE entry for return address is lr or lr+offset, I'll pursue making
gdb accept both.  This is certainly clear while parsing the CIE,
but it is particularly ugly to put a target-dependent test in
this code.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077