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

  Add XML target descriptions for Linux targets.  Compared to default
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.

gdb/ChangeLog:
yyyy-mm-dd  Anton Kolesov  <Anton.Kolesov@synopsys.com>

	* arc-tdep (arc_tdesc_init): Use tdesc_arc_arcompact_linux and
	  tdesc_arc_v2_linux.
	  (_initialize_arc_tdep): Invoke initialize_tdesc_arc_v2_linux and
	  initialize_tdesc_arc_arcompact_linux.
	* features/Makefile: Add targets to generate new files.
	* features/arc-arcompact-linux.xml: New file.
	* features/arc-v2-linux.xml: Likewise.
	* features/arc-arcompact-linux.c: Generate.
	* features/arc-v2-linux.c: Likewise.
	* regformats/arc-arcompact-linux.dat: Likewise.
	* regformats/arc-v2-linux.dat: Likewise.
---
 gdb/arc-tdep.c                         | 17 ++++++-
 gdb/features/Makefile                  |  5 ++
 gdb/features/arc-arcompact-linux.c     | 76 ++++++++++++++++++++++++++++
 gdb/features/arc-arcompact-linux.xml   | 84 +++++++++++++++++++++++++++++++
 gdb/features/arc-v2-linux.c            | 83 +++++++++++++++++++++++++++++++
 gdb/features/arc-v2-linux.xml          | 91 ++++++++++++++++++++++++++++++++++
 gdb/regformats/arc-arcompact-linux.dat | 42 ++++++++++++++++
 gdb/regformats/arc-v2-linux.dat        | 45 +++++++++++++++++
 8 files changed, 441 insertions(+), 2 deletions(-)
 create mode 100644 gdb/features/arc-arcompact-linux.c
 create mode 100644 gdb/features/arc-arcompact-linux.xml
 create mode 100644 gdb/features/arc-v2-linux.c
 create mode 100644 gdb/features/arc-v2-linux.xml
 create mode 100644 gdb/regformats/arc-arcompact-linux.dat
 create mode 100644 gdb/regformats/arc-v2-linux.dat
  

On 17-10-11 17:56:31, Anton Kolesov wrote:
> Add XML target descriptions for Linux targets.  Compared to default

Hi,
I am converting existing GDB target descriptions in a more flexible way
to organize them.  I've done the x86 target descriptions, and slowly
converting tic6x and nios2 target descriptions.  Could you please convert
existing arc target descriptions first?  It is definitely helpful to
simplify this patch.  I had a talk about my work in Cauldron.
https://slideslive.com/38902354/a-flexible-gdb-target-description-for-processor-diversity
If you want to convert existing arc target descriptions, I am happy to
share some steps to do that.

> 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.

> 
> gdb/ChangeLog:
> yyyy-mm-dd  Anton Kolesov  <Anton.Kolesov@synopsys.com>
> 
> 	* arc-tdep (arc_tdesc_init): Use tdesc_arc_arcompact_linux and
> 	  tdesc_arc_v2_linux.
> 	  (_initialize_arc_tdep): Invoke initialize_tdesc_arc_v2_linux and
> 	  initialize_tdesc_arc_arcompact_linux.
> 	* features/Makefile: Add targets to generate new files.
> 	* features/arc-arcompact-linux.xml: New file.
> 	* features/arc-v2-linux.xml: Likewise.
> 	* features/arc-arcompact-linux.c: Generate.
> 	* features/arc-v2-linux.c: Likewise.
> 	* regformats/arc-arcompact-linux.dat: Likewise.
> 	* regformats/arc-v2-linux.dat: Likewise.
> ---
>  gdb/arc-tdep.c                         | 17 ++++++-
>  gdb/features/Makefile                  |  5 ++
>  gdb/features/arc-arcompact-linux.c     | 76 ++++++++++++++++++++++++++++
>  gdb/features/arc-arcompact-linux.xml   | 84 +++++++++++++++++++++++++++++++
>  gdb/features/arc-v2-linux.c            | 83 +++++++++++++++++++++++++++++++
>  gdb/features/arc-v2-linux.xml          | 91 ++++++++++++++++++++++++++++++++++
>  gdb/regformats/arc-arcompact-linux.dat | 42 ++++++++++++++++
>  gdb/regformats/arc-v2-linux.dat        | 45 +++++++++++++++++
>  8 files changed, 441 insertions(+), 2 deletions(-)
>  create mode 100644 gdb/features/arc-arcompact-linux.c
>  create mode 100644 gdb/features/arc-arcompact-linux.xml
>  create mode 100644 gdb/features/arc-v2-linux.c
>  create mode 100644 gdb/features/arc-v2-linux.xml
>  create mode 100644 gdb/regformats/arc-arcompact-linux.dat
>  create mode 100644 gdb/regformats/arc-v2-linux.dat
> 
> diff --git a/gdb/arc-tdep.c b/gdb/arc-tdep.c
> index 771d6df..a825917 100644
> --- a/gdb/arc-tdep.c
> +++ b/gdb/arc-tdep.c
> @@ -42,6 +42,8 @@
>  /* Default target descriptions.  */
>  #include "features/arc-v2.c"
>  #include "features/arc-arcompact.c"
> +#include "features/arc-v2-linux.c"
> +#include "features/arc-arcompact-linux.c"
>  
>  /* The frame unwind cache for ARC.  */
>  
> @@ -1799,13 +1801,22 @@ arc_tdesc_init (struct gdbarch_info info, const struct target_desc **tdesc,
>      {
>        if (is_arcv2)
>  	{
> -	  tdesc_loc = tdesc_arc_v2;
> +	  /* Usually Linux-specific target description would be provided by
> +	     the gdbserver, but it has to be selected manually when debugging
> +	     core files.  */

You need to implement gdbarch method core_read_description in
arc-linux-tdep.c to return the right linux target description.  It doesn't
make much sense to pull in linux target description into arc-tdep.c.

> +	  if (info.osabi == GDB_OSABI_LINUX)
> +	    tdesc_loc = tdesc_arc_v2_linux;
> +	  else
> +	    tdesc_loc = tdesc_arc_v2;
>  	  if (arc_debug)
>  	    debug_printf ("arc: Using default register set for ARC v2.\n");
>  	}
>        else
>  	{
> -	  tdesc_loc = tdesc_arc_arcompact;
> +	  if (info.osabi == GDB_OSABI_LINUX)
> +	    tdesc_loc = tdesc_arc_arcompact_linux;
> +	  else
> +	    tdesc_loc = tdesc_arc_arcompact;
>  	  if (arc_debug)
>  	    debug_printf ("arc: Using default register set for ARCompact.\n");
>  	}
> @@ -2172,6 +2183,8 @@ _initialize_arc_tdep (void)
>  
>    initialize_tdesc_arc_v2 ();
>    initialize_tdesc_arc_arcompact ();
> +  initialize_tdesc_arc_v2_linux ();
> +  initialize_tdesc_arc_arcompact_linux ();
>  
>    /* Register ARC-specific commands with gdb.  */
>  
> diff --git a/gdb/features/Makefile b/gdb/features/Makefile
> index 8a7f377..8d5e3d3 100644
> --- a/gdb/features/Makefile
> +++ b/gdb/features/Makefile
> @@ -44,6 +44,7 @@
>  #   make GDB=/path/to/gdb XMLTOC="xml files" cfiles
>  
>  WHICH = aarch64 \
> +	arc-v2-linux arc-arcompact-linux \

WHICH is used to generate *.dat file from *.xml file.  *.dat files
are used to generate *.c files for GDBserver.  We don't have arc-linux
GDBserver support in this patch, don't need to include this change.
This change can be included in your GDBserver support patches, if you
have.

>  	arm/arm-with-iwmmxt arm/arm-with-vfpv2 arm/arm-with-vfpv3 \
>  	arm/arm-with-neon \
>  	i386/i386 i386/i386-linux \
> @@ -84,6 +85,8 @@ WHICH = aarch64 \
>  
>  # Record which registers should be sent to GDB by default after stop.
>  aarch64-expedite = x29,sp,pc
> +arc-v2-linux-expedite = sp,pc
> +arc-arcompact-linux-expedite = sp,pc

Again, this is used by GDBserver, don't need this change now.  Also,
gdb/features/Makefile have something magic that you only need to define
a generic one,

arc-expedite = sp,pc.
  

Hi Yao,

> -----Original Message-----

> From: Yao Qi [mailto:qiyaoltc@gmail.com]

> Sent: Thursday, October 12, 2017 4:29

> To: Anton Kolesov <Anton.Kolesov@synopsys.com>

> Cc: gdb-patches@sourceware.org; Francois Bedard

> <Francois.Bedard@synopsys.com>

> Subject: Re: [PATCH 1/3] arc: Add XML target descriptions for Linux targets

> 

> On 17-10-11 17:56:31, Anton Kolesov wrote:

> > Add XML target descriptions for Linux targets.  Compared to default

> 

> Hi,

> I am converting existing GDB target descriptions in a more flexible way to

> organize them.  I've done the x86 target descriptions, and slowly converting

> tic6x and nios2 target descriptions.  Could you please convert existing arc

> target descriptions first?  It is definitely helpful to simplify this patch.  I had a

> talk about my work in Cauldron.

> https://urldefense.proofpoint.com/v2/url?u=https-

> 3A__slideslive.com_38902354_a-2Dflexible-2Dgdb-2Dtarget-2Ddescription-

> 2Dfor-2Dprocessor-

> 2Ddiversity&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=bGeZp_Q7bzMjry

> uhhu0vBa43pSPPzpiFmLmHs_6WFqE&m=MppHij0o6FxrwL3TgkCMii1KKmHt_

> nSJaMNwdq8BcUk&s=XrFH1QC31ZrbgC4h4uHLGWxV6YuN5Nz2Q_rGtBg2k_k

> &e=

> If you want to convert existing arc target descriptions, I am happy to share

> some steps to do that.

> 

> > 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 multiple problems:
- order of registers in "info registers" will not match architectural numbers of registers.
- that would add two XML features because of three registers. Considering amount of code that is needed for each feature it doesn't look like a good tradeoff. Especially since this should be propogated to each and every gdbserver that works with ARC.to produce XML target descriptions that match GDB expectations - almost all of them generate descriptions based on what are the actual registers in the target CPU - gdbserver in GDB is the only one that uses files from gdb/features/. 
- and that still before we tackle the true complexity of 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).
- in addition for each XML feature there is a need to create separate code in arc_gdbarch_init, and feature-reading code tends to be a verbose copy paste with minor edits, so removal of copy-paste in XML files adds more copy paste in GDB code and even more complexity at the side of gdbserver (and some gdbservers are not maintained by Synopsys, so updating them is complicated), so having "fixed" XML features always looked to me like a bad idea for the case of ARC.

That's why I've historically decided to 


If I extract R58, R59 and ILINK/R29 into separate features, then registers will lose their order in "info registers", so R29 will be after R30, blink/R31 or loop_counter/R60. Furthermore, if we extend the paradigm that feature should have a fixed set of register, then things go very bad if we consider a reduced register set configuration for ARC (16 core registers instead of 32) - it creates more holes in the feature. So there would be feature for always-present registers (R0-R3, R10-R15, R26-R28, R30-R31, R63), then registers added in normal configuration (R4-R9, R16-R25), then separate features for R29/ILINK, for R58+R59, for LP_COUNT/R60 (strictly speaking it is optional, though it almost always present). Things get even more complicated if we consider that chip designer can add their own extension registers R32-R57. One option is of course to just add separate XML features for each group of registers to make sure that order of registers in GDB matches architectural order, or to write a more complex logic in the arc_gdbarch_init so it would interleave scanning of different features to maintain order.

Even if we ignore reduced register set case and ordering of registers, it means that I need to split "core" feature into:
- always present: R0 - R28, BLINK, LP_COUNT, PCL
- present at baremetal only : R29
- multiplier (present at Linux, maybe present at baremetal): R58, R59
- flexible feature for extension core registers, that allows to insert R30-R57 when any one is present.

Then those changes should be implemented in several GDBservers that work with ARC (most of them generate their own XML target description based on what registers are actually present or not present in the target CPU)
  

Sorry that email wasn't finished, sent by mistake :)

I'm still researching the topic.

Anton

> -----Original Message-----

> From: Anton Kolesov [mailto:akolesov@synopsys.com]

> Sent: Wednesday, October 18, 2017 18:07

> To: Yao Qi <qiyaoltc@gmail.com>; Anton Kolesov

> <Anton.Kolesov@synopsys.com>

> Cc: gdb-patches@sourceware.org; Francois Bedard

> <Francois.Bedard@synopsys.com>

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

> 

> Hi Yao,

> 

> > -----Original Message-----

> > From: Yao Qi [mailto:qiyaoltc@gmail.com]

> > Sent: Thursday, October 12, 2017 4:29

> > To: Anton Kolesov <Anton.Kolesov@synopsys.com>

> > Cc: gdb-patches@sourceware.org; Francois Bedard

> > <Francois.Bedard@synopsys.com>

> > Subject: Re: [PATCH 1/3] arc: Add XML target descriptions for Linux

> > targets

> >

> > On 17-10-11 17:56:31, Anton Kolesov wrote:

> > > Add XML target descriptions for Linux targets.  Compared to default

> >

> > Hi,

> > I am converting existing GDB target descriptions in a more flexible

> > way to organize them.  I've done the x86 target descriptions, and

> > slowly converting tic6x and nios2 target descriptions.  Could you

> > please convert existing arc target descriptions first?  It is

> > definitely helpful to simplify this patch.  I had a talk about my work in

> Cauldron.

> > https://urldefense.proofpoint.com/v2/url?u=https-

> > 3A__slideslive.com_38902354_a-2Dflexible-2Dgdb-2Dtarget-2Ddescription-

> > 2Dfor-2Dprocessor-

> >

> 2Ddiversity&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=bGeZp_Q7bzMjry

> >

> uhhu0vBa43pSPPzpiFmLmHs_6WFqE&m=MppHij0o6FxrwL3TgkCMii1KKmHt_

> >

> nSJaMNwdq8BcUk&s=XrFH1QC31ZrbgC4h4uHLGWxV6YuN5Nz2Q_rGtBg2k_k

> > &e=

> > If you want to convert existing arc target descriptions, I am happy to

> > share some steps to do that.

> >

> > > 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 multiple

> problems:

> - order of registers in "info registers" will not match architectural numbers of

> registers.

> - that would add two XML features because of three registers. Considering

> amount of code that is needed for each feature it doesn't look like a good

> tradeoff. Especially since this should be propogated to each and every

> gdbserver that works with ARC.to produce XML target descriptions that

> match GDB expectations - almost all of them generate descriptions based on

> what are the actual registers in the target CPU - gdbserver in GDB is the only

> one that uses files from gdb/features/.

> - and that still before we tackle the true complexity of 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).

> - in addition for each XML feature there is a need to create separate code in

> arc_gdbarch_init, and feature-reading code tends to be a verbose copy paste

> with minor edits, so removal of copy-paste in XML files adds more copy paste

> in GDB code and even more complexity at the side of gdbserver (and some

> gdbservers are not maintained by Synopsys, so updating them is

> complicated), so having "fixed" XML features always looked to me like a bad

> idea for the case of ARC.

> 

> That's why I've historically decided to

> 

> 

> If I extract R58, R59 and ILINK/R29 into separate features, then registers will

> lose their order in "info registers", so R29 will be after R30, blink/R31 or

> loop_counter/R60. Furthermore, if we extend the paradigm that feature

> should have a fixed set of register, then things go very bad if we consider a

> reduced register set configuration for ARC (16 core registers instead of 32) - it

> creates more holes in the feature. So there would be feature for always-

> present registers (R0-R3, R10-R15, R26-R28, R30-R31, R63), then registers

> added in normal configuration (R4-R9, R16-R25), then separate features for

> R29/ILINK, for R58+R59, for LP_COUNT/R60 (strictly speaking it is optional,

> though it almost always present). Things get even more complicated if we

> consider that chip designer can add their own extension registers R32-R57.

> One option is of course to just add separate XML features for each group of

> registers to make sure that order of registers in GDB matches architectural

> order, or to write a more complex logic in the arc_gdbarch_init so it would

> interleave scanning of different features to maintain order.

> 

> Even if we ignore reduced register set case and ordering of registers, it

> means that I need to split "core" feature into:

> - always present: R0 - R28, BLINK, LP_COUNT, PCL

> - present at baremetal only : R29

> - multiplier (present at Linux, maybe present at baremetal): R58, R59

> - flexible feature for extension core registers, that allows to insert R30-R57

> when any one is present.

> 

> Then those changes should be implemented in several GDBservers that work

> with ARC (most of them generate their own XML target description based on

> what registers are actually present or not present in the target CPU)
  

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