This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, nios2] Use "sstatus" as preferred name of r30


On 10/14/2013 03:04 AM, Pedro Alves wrote:
Hi Sandra,

On 10/14/2013 02:08 AM, Sandra Loosemore wrote:
Altera has requested that the register r30 disassemble using the
symbolic name "sstatus" rather than "ba". Both names are documented in
the Nios II processor reference handbook.

The binutils changes to support this are already checked in:
https://sourceware.org/ml/binutils/2013-10/msg00211.html

I've also checked in this patch to make the corresponding changes to
GDB's lists of register names.

I think this means that GDB will no longer accept target descriptions
that used the old register name?

That's true, but I don't think we (or Altera) care very much about maintaining backward compatibility at this point, especially for GNU/Linux targets. The previously checked-in set of register names was already incompatible with the out-of-tree GDB port that was available for some years from Altera and CodeSourcery/Mentor Graphics. We're also presently working on kernel/GLIBC ABI changes that are incompatible with the existing out-of-tree ports of those components as well. When those pieces are finished, anything built against an older kernel or GLIBC will be obsolete anyway.... and that includes old gdbserver executables.

Not sure this is a good idea.  An older gdb against a newer gdbserver
will also not accept the target description for not finding "ba"
in the org.gnu.gdb.nios2.cpu feature.

If we want to change the description, then I think we should
do it with new alternative target descriptions and features instead.

But since this is a core register that GDB knows about, another option
would be to leave the "ba" spelling in the descriptions as it was,
and instead special case r30 in nios2_register_name.

I suppose we could do something to future-proof this code. I'll think a little about whether there is a tidy way to do it.

-Sandra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]