RE: [PATCH 1/3] arc: Add XML target descriptions for Linux targets

[Anton Kolesov <Anton dot Kolesov at synopsys dot com>]

Hi Yao,

(This is a right email this time).

> 
> > Linux descriptions:
> >
> > - Explicitly specify CPU machine.
> > - Remove baremetal only ILINK{,1,2} registers.
> > - Add LP_START and LP_END registers for hardware loops - required to
> properly
> >   evaluate possible next instruction during software single instruction
> >   stepping.
> > - Add BTA register which contains branch target address - address of next
> >   instruction when processor is in the delay slot.
> > - ARC HS description also adds R30, R58 and R59 registers, specific to this
> >   architecture.
> 
> IMO, it is not a good practise to linux and non-linux target descriptions have
> target features of the same name, but same target features have trivial
> differences, as you described above.  The common practise we did is to
> define each target feature xml file, and use xi:include to "include"
> each target feature into target description.  All existing target descriptions
> follow this approach.
> 

If I extract R58, R59 and ILINK/R29 into separate features that would create
multiple problems:

- order of registers in "info registers" will not match architectural numbers
  of registers.
- that would add two XML features because of just three registers. Considering
  amount of code that is needed in *-tdep.c files for each feature it
  doesn't look like a good trade off. Especially since this should be
  propagated to each and every RSP-server that works with ARC, so that they will
  produce XML target descriptions that matches GDB expectations - almost all of
  them generate descriptions based on what are the actual registers in the
  target CPU - RSP-server in GDB is the only one that uses files from
  gdb/features/. So adding new features to make sure that each feature is fixed
  in its content will add a lot of code overall, but I’m not sure what would be
  an advantage of this. GDB accepts arbitrary XML features, but explicit
  C++-code still should be written for an XML feature if there is a need for
  alternative names or a specific internal number for a register.
- and things get worse if we consider other optional registers in ARC: there
  are extension core registers R32-R57 that can be added by hardware designers;
  there is a "reduced register file" configuration where many core registers
  are removed, but there are two groups of registers removed, so extracting
  them into separate features would also break order of register (R4 will be
  after R31, etc).

That's why in the past I've decided that it is better to have few features, but
allow content of features to be flexible - that allows for simple
implementation in GDB, RSP-servers and also helped with transition from the
pre-XML target descriptions system that was used in GDB fork for ARC.  Creating
strict features for ARC baseline registers always looked to me us a feasible,
but an unnecessarily complex task without clear benefit.  Many of ARC registers
(not mentioned in GDB anywhere) can be grouped into features successfully, but
the core register set doesn't map well into XML features, I think, because
there is so much of intermix between optional and non-optional registers.
Things would be easier if it would be possible to include another XML file
without having a separate feature in that file.

What, I think, I can do is to designate a separate XML feature for Linux, so
that the content will not clash with a generic "core.arcv2" feature.  List of
registers available on Linux is fairly certain and fixed, because it depends on
Linux rather than on hardware and our Linux port support only certain CPU
configuration. Plus there is only one GDBserver for Linux targets and it is a
part of GDB itself. However that would be a single feature, so it still will
not be able to include registers written in other xml files. But for baremetal
I'd prefer to keep the current XML features that allow for semi-arbitrary list
of registers, especially since I need to maintain compatibility with existing
RSP-servers.

Anton