Re: Unreviewed patches

[Andrew Cagney <ac131313@ges.redhat.com>]

> Andrew Cagney wrote:
> 
>> 
> 
>> >
>> > I think the stashing of constants into the tdep structure is basically
>> > wrong.  You separate the register names arrays from the literals
>> > that describe their positions, and you replicate the literals
>> > up to four times.  The tdep structure and the sh_gdbarch_init
>> > function are so large that you have lost track of the things that
>> > really belong in tdep, like sh_show_regs, skip_prologue_hard_way,
>> > and do_pseudo_register.  If you look at other gdb ports, you'll
>> > see that they put only variable stuff in tdep, and use enums
>> > for constants.  The sh gdb register naming scheme also doesn't
>> > scale well, the names are again duplicated multiple times.
> 
>> 
>> Can i suggest comparing the SH with the MIPS or RS6000.


> MIPS and RS6000 use varying register numbers for hardware registers
> with identical name and function.  I suppose that is due to historical
> accident?

If it happened once it would be an accident.

In the good old days, GDB was built for a specific CPU.  The register 
layout (along with the G packet) was hard wired using constants from the 
tm*.h files.  Each CPU variant had a different register layout (for 
efficiency reasons).

Targets like the SH would then add a limited form of CPU variant support 
using patches like:

Mon May 15 21:27:27 2000  J"orn Rennecke <amylaar@cygnus.co.uk>

         * sh-tdep.c (sh_dsp_reg_names, sh3_dsp_reg_names): New arrays.
         (sh_processor_type_table): Add entries for bfd_mach_sh_dsp and
          bfd_mach_sh3_dsp.

It was implemented by modifying the register name tables (along with a 
few other structures) directly.

In the mean time, people have been replacing that code with code using 
the multi-arch framework.  In doing this conversion, the technique of 
replacing hardwired constants with variables has proven most effective. 
  This is because it lets the developer complete their multi-arch task 
independant of any other longer term changes that GDB may require.

enjoy,
Andrew