This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 1/3] arc: Add XML target descriptions for Linux targets
- From: Anton Kolesov <Anton dot Kolesov at synopsys dot com>
- To: Anton Kolesov <Anton dot Kolesov at synopsys dot com>, Yao Qi <qiyaoltc at gmail dot com>, Anton Kolesov <Anton dot Kolesov at synopsys dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Francois Bedard <Francois dot Bedard at synopsys dot com>
- Date: Wed, 18 Oct 2017 15:07:50 +0000
- Subject: RE: [PATCH 1/3] arc: Add XML target descriptions for Linux targets
- Authentication-results: sourceware.org; auth=none
- References: <20171011145633.19343-1-Anton.Kolesov@synopsys.com> <20171012012859.GJ8425@1170ee0b50d5> <39A54937CC95F24AA2F794E2D2B66B135895D58A@DE02WEMBXB.internal.synopsys.com>
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)