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

[Anton Kolesov <Anton.Kolesov@synopsys.com>]

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)